[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Y2K
   From: Zefram <>
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

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

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

 \ /
  Last update: 2005-03-22 13:43    [W:0.103 / U:3.264 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site