The upcoming Y2038 catastrophe

[bob]

The above code will not survive the Y2038 transition.

Yes, it will. I just checked on my Linux machine and tv_sec has type time_t, which is a 64-bit integer. It has already been solved, at least on some implementations. It is likely the case that some implementations today still use 32-bit integers for time_t, but I don't think there is much risk of this actually being a problem in 2038.

It won't work on Mac OS/X Intel, because there sizeof(time_t) is four.

This may not be too important for Apple as by 2038 their only products might be fashion and jewelry.

It will be a big problem for embedded systems which outnumber desktops and notebooks and which can't be easily upgraded.

For regular computers, fixing the libraries and recompiling applications is not enough; all or nearly all of the current filesystems in use will have to be converted along with all their backed up data.

I am running Mavericks 10.9.5 here. Here is a sample program:

#include <stdio.h>
#include <unistd.h>
main() {
printf("sizeof=%d\n", sizeof(time_t));
}

And here's the output on my iMac i7 quad:

crafty% ./tst
sizeof=8
crafty%

That's not going to wrap for a LONG time. Approximately 4B * 68 years.

[sje]

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.

[syzygy]

Code: Select all

gettimeofday(&tval, 0);

gettimeofday should not be used to measure elapsed time. You should use clock_gettime(CLOCK_MONOTONIC) or an equivalent function of your OS instead. If the time of our system is adjusted (by a user or automatically), gettimeofday can return a wrong value.

If you let users adjust the system time, you already have a major security problem. Far worse than the potential time wrap problem Steven was talking about.

On any system there will be someone with root access. That is not a security problem.

There is also the ntp daemon that may adjust the clock. It does this gradually without big leaps, but I doubt that this is guaranteed to be monotonic on all systems.

[bob]

Code: Select all

gettimeofday(&tval, 0);

gettimeofday should not be used to measure elapsed time. You should use clock_gettime(CLOCK_MONOTONIC) or an equivalent function of your OS instead. If the time of our system is adjusted (by a user or automatically), gettimeofday can return a wrong value.

If you let users adjust the system time, you already have a major security problem. Far worse than the potential time wrap problem Steven was talking about.

On any system there will be someone with root access. That is not a security problem.

There is also the ntp daemon that may adjust the clock. It does this gradually without big leaps, but I doubt that this is guaranteed to be monotonic on all systems.

Please read. A system admin is not normally called a "user". ntpd allows a perfectly simple way of manually adjusting the system time that prevents big steps. Adjusting the clock manually is a well-known no-no unless you are the only user. You screw up timestamps, things like make, cvs, you-name-it. There are better and more correct solutions.

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.

[syzygy]

Code: Select all

gettimeofday(&tval, 0);

gettimeofday should not be used to measure elapsed time. You should use clock_gettime(CLOCK_MONOTONIC) or an equivalent function of your OS instead. If the time of our system is adjusted (by a user or automatically), gettimeofday can return a wrong value.

If you let users adjust the system time, you already have a major security problem. Far worse than the potential time wrap problem Steven was talking about.

On any system there will be someone with root access. That is not a security problem.

There is also the ntp daemon that may adjust the clock. It does this gradually without big leaps, but I doubt that this is guaranteed to be monotonic on all systems.

Please read. A system admin is not normally called a "user".

So let's read again:

If the time of our system is adjusted (by a user or automatically), gettimeofday can return a wrong value.

If it's the system admin that changes the time, gettimeofday can somehow not return a wrong value?

And again, ntpd is not guaranteed to adjust the clock in an absolutely monotonic manner.

This is not worth my time, so just go ahead twisting and turning and fooling yourself.

[mar]

gettimeofday should not be used to measure elapsed time. You should use clock_gettime(CLOCK_MONOTONIC) or an equivalent function of your OS instead.

Yes, this is something that bothers me. Unfortunately CLOCK_MONOTONIC is not available on OSX and clock_get_time may be changed by calling clock_set_time, so a similar problem.
EDIT: clock_set_time seems to do nothing so perhaps this would be a way

[sje]

I'm gonna buy me one of these here gizmos:

http://www.aventasinc.com/product_info. ... ts_id=2783

After I install it, I'll delete the root account on my system, disconnect the network cable, and refuse all software updates so that time, may indeed, march on.

Or I can just continue with gettimeofday() and ntpd, neither of which have failed me yet.

[bob]

Code: Select all

gettimeofday(&tval, 0);

gettimeofday should not be used to measure elapsed time. You should use clock_gettime(CLOCK_MONOTONIC) or an equivalent function of your OS instead. If the time of our system is adjusted (by a user or automatically), gettimeofday can return a wrong value.

If you let users adjust the system time, you already have a major security problem. Far worse than the potential time wrap problem Steven was talking about.

On any system there will be someone with root access. That is not a security problem.

There is also the ntp daemon that may adjust the clock. It does this gradually without big leaps, but I doubt that this is guaranteed to be monotonic on all systems.

Please read. A system admin is not normally called a "user".

So let's read again:

If the time of our system is adjusted (by a user or automatically), gettimeofday can return a wrong value.

If it's the system admin that changes the time, gettimeofday can somehow not return a wrong value?

And again, ntpd is not guaranteed to adjust the clock in an absolutely monotonic manner.

This is not worth my time, so just go ahead twisting and turning and fooling yourself.

Sorry, go read up on ntpd. It GUARANTEES that the clock adjustments are applied fractionally so that there is NEVER any step backward. And as it learns how time slips on a specific machine, it gets even better in that it slowly adjusts the clock throughout the day, even between samples.

Keep imagining how things work rather than reading the ntp RFC or looking at how it works. It was SPECIFICALLY created to avoid backward time steps. Or large forward time steps. It does not do EITHER.

Of course it isn't worth your time. It apparently wasn't even worth your time to read up on how it actually works. Some of us have been running this for 30 years or so. It addresses ALL of the issues caused by super-user time adjustments as well as different rates of time slip across different machines...

read, read, read...

[bob]

I'm gonna buy me one of these here gizmos:

http://www.aventasinc.com/product_info. ... ts_id=2783

After I install it, I'll delete the root account on my system, disconnect the network cable, and refuse all software updates so that time, may indeed, march on.

Or I can just continue with gettimeofday() and ntpd, neither of which have failed me yet.

We bought a group of sun workstations in late 1985 or so. First problem many of us encountered was using NFS to access files and using make to compile. If the workstations have time slip, and you try to distribute your compiles over the group of workstations, chaos ensues when the dates cause some machines to recompile something, while others don't due to incorrect dates/times.

ntp cured it quickly, easily, and avoided the discontinuity problem since when it contacts one of the upper-level servers and discovers local time is off, it doesn't just stuff the correct time into the system counter, it slowly advances it so that it behaves rationally, and then it monitors the amount of correction so that it continuously updates the time so that smaller corrections are needed at time sync points.

This is REALLY old stuff for unix users. I don't know when it was ported to windows, since microsoft is always late to these parties. Clusters would be a real problem without ntpd, in fact.

[sje]

We bought a group of sun workstations in late 1985 or so. First problem many of us encountered was using NFS to access files and using make to compile. If the workstations have time slip, and you try to distribute your compiles over the group of workstations, chaos ensues when the dates cause some machines to recompile something, while others don't due to incorrect dates/times.

It was back in 1986 that I got my first Apple computer, a Mac Plus which I used to write my chess program Spector. The Mac Plus had a battery backed RTC (real time clock), a not very common feature of that day. And the chip used for the RTC was not all that great; in fact, mine failed soon after I bought the machine -- the RTC would slow, then freeze after the computer had been running for much more than an hour. I had to pay for an AppleCare insurance package to have the main board replaced because I didn't notice the failure until after the stingy 90 day warranty had expired. Moral of story: Be cautious in trusting your computer's time keeping ability.

Anyway, in the days before the Web, it was possible to use a dial-up modem to connect to an Internet timeserver. And that's what I did with my Mac Plus and a 2400 bps Hayes SmartModem. This kept the time on my Plus accurate to within a second or so of the real time at the cost of a weekly long distance phone call.

Accessing the RTC via a library routine was not very fast, and I wanted Spector to be able to check the elapsed time for a search at every node. So I used the Macintosh-specific Ticks() routine. This routine, if I recall correctly, was actually a macro which read a fixed location global 32 bit integer which counted the number of 60 Hz video refreshes since booting. The rollover period was about 829 days, a bit longer than the average life expectancy of a Mac Plus power supply and many times that of the mean period between New England power outages.

Today, Symbolic uses a descendant of the Ticks() routine; the program calls the C library routine setitimer() to generate a 10 millisecond periodic signal. This signal is caught by a handler which increments a global tick counter, and that's the counter read at every node to allow the search to stop on a dime with very little overhead. This technique works quite well and I recommend it to my fellow authors whose programs are to run an a Unix system.

Programming note: When deactivating an interval timer, on some systems it may be necessary to wait three or more interval periods for the deactivation to go into effect, so don't disable the signal handler until it's safe to do so.

Code: Select all

#define TickFreqLen 100 // Tick frequency in Hertz
#define TUSecLen    1000000ull
#define TickTimeLen (TUSecLen / TickFreqLen)

void Driver::IntervalTimerInit(void)
{
  Log("Interval timer initializing");

  TickCount = 0;
  UsecCount = 0;

  struct itimerval itval0, itval1;

  TimeValFromTU(TickTimeLen, itval0.it_interval);
  TimeValFromTU(TickTimeLen, itval0.it_value);
  if (setitimer(ITIMER_REAL, &itval0, &itval1) != 0)
    Die("IntervalTimerInit", "Bad setitimer");
}

void Driver::IntervalTimerTerm(void)
{
  Log("Interval timer terminating");

  struct itimerval itval0, itval1;

  ZeroToTimeVal(itval0.it_interval);
  ZeroToTimeVal(itval0.it_value);
  if (setitimer(ITIMER_REAL, &itval0, &itval1) != 0)
    Die("IntervalTimerTerm", "Bad setitimer");
  usleep(TickTimeLen * 3);
}