Messages in this thread | | | Date | Tue, 23 Jun 1998 15:12:43 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Y2K |
| |
From: Zefram <zefram@tao.co.uk> Date: Tue, 23 Jun 1998 11:30:02 +0100 (BST)
# *seconds since the Epoch*: A value to be interpreted as the number of # seconds between a specified time and the Epoch. # # A Coordinated Universal Time name (specified in terms of seconds (tm_sec), # minutes (tm_min), hours (tm_hour), days since January 1 of the year # (tm_yday), and calendar year minus 1900 (tm_year) is related to a time # represented as seconds since the Epoch according to the expression below. # # If the year < 1970 or the value is negative, the relationship is # undefined. If the year >= 1970 and the value is nonnegative, the value is # related to a Coordinated Universal Time name according to the expression: # # tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + # (tm_year-70)*31536000 + ((tm_year-69)/4)*86400
This unambiguously is *not* literally "seconds since the Epoch"; it is the number of seconds since the Epoch minus the number of leap seconds since the Epoch.
Actually, what I see this as is that tm_sec, tm_min, tm_hour, et. al. don't exactly correspond to the seconds, minutes, and hours as measured by UTC. So "real time" might be 15:04:14, but tm_sec will be 14 seconds different from "real time". Seconds since the epoch are indeed still "seconds since the epoch" --- and regardless of whatever else we did, that definition was probably the correct one. We want the time returned by time(0) to be a monotonically increasing number that doesn't deal with slipping a second to deal with leap seconds.
The questionable decision at least in my mind is the translation between "seconds since the Epoch" and struct tm. The POSIX definition ignores leaps seconds when defining the conversion. It probably would have been a better idea to take leap seconds into account when doing time conversions, although this does cause other problems, such as different Unix systems doing different things depending on when the system was last updated (the Time standards folks only give roughly 6 months warning or less before adding or removing a leap second); so unless you keep your Unix machine constantly up to date, your ctime() may return a different result from your neighbor's ctime(), depending on when the leap second table on your machine was last updated. Presumably the POSIX people decided this was too horrible, and decided to punt on the issue.
My take on this is that it is not the POSIX committee's finest hour. They have, as usual, examined the various poorly-specified systems in common use, invented a compromise that satisfies no one, and been unsurprisingly unable to write it up as a logical and self-consistent standard.
I agree that this wasn't their finest hour, but there really isn't a good solution to this problem. Their solution is self-consistent and well defined, IMO. To quote their rationale, "it is important that all conforming systems interpret "536 457 599 seconds since the Epoch" as 59 seconds, 59 minutes, 23 hours 31 December 1986". If this is the goal (and there are valid reasons for that goal --- take for example network protocols that send times around as "19861231235959Z") then their solution is the only valid one, given that when leap seconds occur is not predictable more than a few months in advance.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |