The upcoming Y2038 catastrophe

[syzygy]

By far, a properly configured ntpd is the most commonly used and least problematic time fix that doesn't wreck things.

And for the record, ANYONE running with root access is absolutely a security risk. I don't think you can find a single person on the planet that has not broken something while running as root. Which is why most of us with any experience do not use root as our working account.

Not everybody is running a cluster of servers. On tablets, laptops, etc., with intermittent network connections, ntpd is not working as you except. If the time deviation is big enough (1000s), ntpd is not going to correct anything, and you have to change the time manually. For smaller time deviation, ntpd can call settimeofday and produce big time jump if you are using the obsolescent settimeofday function. This is only for small time deviation that ntpd works as you describe it. On a permanently connected computer, only small deviations may occur, but in real life, not all computer are permanently connected.

Sorry, go read up on ntpd. It GUARANTEES that the clock adjustments are applied fractionally so that there is NEVER any step backward.

Of course in Bob's dictionary never does not mean never, and guarantee does not mean guarantee. And of course we should all have known that. (And in fact we all do, unfortunately. Those forum trolls...)

[lucasart]

I remember the famous, and long foretold back then, "Y2K bug". It was supposed to be a cataclysm, that would extinguish entire civilisations, etc.

People were buying placebo software, to install on their computers, and see if they were Y2K immune.

Then came 1-jan-2000. Nothing happened, really. Probably a few issues, like some machines had to be rebooted, or what not. But I don't remember that the world stopped spinning as a result.

Y2038 is a business opportunity
* now is the time for fear mongering.
* once the fear has taken everyone, you can propose some placebo software at extortionate price, to company's business managers (especially if they are not IT savvy, hence gullible).

[Evert]

I looks like sizeof(time_t) on OS/X Mavericks is 8; on OS/X Tiger it is 4.

On OS/X Lion, it appears to be 8, but the definition drill down in Xcode says 4.

It depends on whether you compile as a 32 bit or as a 64 bit binary. If I compile as 64 bit, sizeof(time_t) is 8, if I compile a 32 bit binary, it is 4.

Makes sense: when defining the 64 bit ABI, you can fix the problem quietly without the risk of breaking existing binaries. Of course, that doesn't fix timestamps recorded in meta-data (or file systems), but that can be worked around or phased out.

[bob]

Perhaps gettimeofday has been good enough for the purpose of measuring thinking times in crafty, but it is true that it is not the right tool for the job of measuring elapsed time between events in general.

I understand Mr. Hyatt is unlikely to change his mind, because it's not his M.O., but perhaps others are following this conversation and want to know who is right. For those people, here's a link: http://blog.habets.pp.se/2010/09/gettim ... asure-time

The discussion was not about "which is most accurate". It was about does ntp provide a monotonic clock, which it does unless someone interferes. If you want a really accurate measure, you can always access the CPU cycle counter.

NTP on a lan produces distributed clock accuracy of 1ms or less, which was the goal. It also does not cause the clock to step backward so long as no root user dinks around with the system time on the ntp server. That was what the discussion was about.

[bob]

I have no idea what you quoted any of that for.

Short-term memory problems, right?

It GUARANTEES that the clock adjustments are applied fractionally so that there is NEVER any step backward.

I've just spelt out for you how wrong you are.

Of course you go on saying you are right.

When you boot up there can be negative steps.
Or when you you go offline for a while and reconnect.
Or when you close the lid and open it after some time.

There are no negative steps, except when there are.

"when you boot up" who cares? You can't run until the boot is completed, so there is no problem. When you go offline for a while and reconnect, time doesn't step backward. Possibly forward. When you close the lid and suspend, and then open it, time will have to step forward to catch up, but not backward...

I am not sure what this is supposed to have to do with a monotonic clock discussion. closing the lid is human interference. As is rebooting. This is more common:

10:22:18 up 151 days, 22:28, 1 user

never suspended, not rebooted for 5 months (for a kernel update), etc... And during that time, one didn't see the clock bouncing around...

As I said, with no human interference, it really does work well, and does exactly what it was designed to do, which is to make these problems non-problems...

If you want negative steps, you can always use su or sudo and manually set the clock to some future time. If you call that a weakness, I have a solution, namely removing the date command so that you can't, then the time will be correct without interference.

[bob]

By far, a properly configured ntpd is the most commonly used and least problematic time fix that doesn't wreck things.

And for the record, ANYONE running with root access is absolutely a security risk. I don't think you can find a single person on the planet that has not broken something while running as root. Which is why most of us with any experience do not use root as our working account.

Not everybody is running a cluster of servers. On tablets, laptops, etc., with intermittent network connections, ntpd is not working as you except. If the time deviation is big enough (1000s), ntpd is not going to correct anything, and you have to change the time manually. For smaller time deviation, ntpd can call settimeofday and produce big time jump if you are using the obsolescent settimeofday function. This is only for small time deviation that ntpd works as you describe it. On a permanently connected computer, only small deviations may occur, but in real life, not all computer are permanently connected.

OK, HOW does the time deviation reach 1000s? Only by human interference. Which means nothing will work if a human is in the middle of the process. How else does the clock get off that far?

(1) shutdown and a later reboot? an ntpdate during boot solves that, before ntpd decides to give up and quit. That's automatic on boot up.

(2) a suspend/wake on a laptop (closing the lid)? The wakeup will correct the clock if things are set up correctly. Again, no problem.

Are you going to do EITHER of those while playing a chess game where a monotonic clock is important? If you WANT to break anything, you can. But if you let ntpd run, and leave it alone, you get exactly the effect most want. Which is an accurate clock across all machines you are using so that Make does not get confused, a monotonic clock so that you don't have to deal with negative intervals, etc.

[bob]

By far, a properly configured ntpd is the most commonly used and least problematic time fix that doesn't wreck things.

And for the record, ANYONE running with root access is absolutely a security risk. I don't think you can find a single person on the planet that has not broken something while running as root. Which is why most of us with any experience do not use root as our working account.

Not everybody is running a cluster of servers. On tablets, laptops, etc., with intermittent network connections, ntpd is not working as you except. If the time deviation is big enough (1000s), ntpd is not going to correct anything, and you have to change the time manually. For smaller time deviation, ntpd can call settimeofday and produce big time jump if you are using the obsolescent settimeofday function. This is only for small time deviation that ntpd works as you describe it. On a permanently connected computer, only small deviations may occur, but in real life, not all computer are permanently connected.

Sorry, go read up on ntpd. It GUARANTEES that the clock adjustments are applied fractionally so that there is NEVER any step backward.

Of course in Bob's dictionary never does not mean never, and guarantee does not mean guarantee. And of course we should all have known that. (And in fact we all do, unfortunately. Those forum trolls...)

Nobody can prevent stupidity. But if you boot a machine, run ntpd, and leave it alone with no super-user time adjustments just to see if you can break it, it will run flawlessly and as advertised. If you want to be stupid and intentionally break it, you can. My fix is to not have super-users running around, period. Then there is not a problem except for rebooting and that isn't a problem since the time is fixed on startup before anyone can run anything...

So my "never" means "never, unless human stupidity is involved." --you just can't fix "stupid".

[bob]

I remember the famous, and long foretold back then, "Y2K bug". It was supposed to be a cataclysm, that would extinguish entire civilisations, etc.

People were buying placebo software, to install on their computers, and see if they were Y2K immune.

Then came 1-jan-2000. Nothing happened, really. Probably a few issues, like some machines had to be rebooted, or what not. But I don't remember that the world stopped spinning as a result.

Y2038 is a business opportunity
* now is the time for fear mongering.
* once the fear has taken everyone, you can propose some placebo software at extortionate price, to company's business managers (especially if they are not IT savvy, hence gullible).

There were issues. Just not earth-shattering issues. I know of an airline that had zero flight crews show up on Jan 2, 2000, nor any airport staff, nothing. Airtram from Orlando to Atlanta. The scheduling program was broken and failed to schedule any flight crews or staff for the first 3 days of 2000. I had a credit card declined when renting a car, because the system would not accept the expiration date.

Fortunately, 2038 won't likely even be noticed since most systems now use a 64 bit seconds-since-epoch counter.

[sje]

If you can read this, then it likely means that you can connect to the Internet. And that means that your machine can use nntp to get the current time. Therefore, unless your software is misconfigured, your hardware is horribly buggy, or you have an idiot for a system administrator, then once your Internet connected machine finishes booting its idea of the current time will never be incorrect by thousands of seconds, or even a single second.

Over several decades, many smart guys combined with many millions of taxpayer dollars have produced an incredibly accurate network time infrastructure. This system includes careful averaging of multiple independent cesium clocks distributed around the planet. The long term performance of the individual clocks is well known, and even better clocks are developed over the years. This is what drives nntp, and gettimeofday() combines that with its own long term observations of its host to produce an almost incredibly accurate value of the current time.

Is gettimeofday() fed by nntp as good as a local cycle counter for measuring intervals? It's actually far superior, because that local counter is from a single source time base that is unlikely to be corrected for thermal drift. Further, that local counter will produce interval measurements which are never compared with nor corrected by those produced by a counter on a different chunk of hardware. This means that a nodes per second frequency measurement can't be compared among different machines using only local counters because each machine will have its own idea as to the length of a second.

[Evert]

If you can read this, then it likely means that you can connect to the Internet. And that means that your machine can use nntp to get the current time. Therefore, unless your software is misconfigured, your hardware is horribly buggy, or you have an idiot for a system administrator, then once your Internet connected machine finishes booting its idea of the current time will never be incorrect by thousands of seconds, or even a single second.

What happens with daylight savings?
I suppose I could just look it up, but I guess the smart way of dealing with that is having the clock use UT and only change the timezone for conversion to local time.