`   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 asmeasured by UTC.  So "real time" might be 15:04:14, but tm_sec will be14 seconds different from "real time".    Seconds since the epoch areindeed still "seconds since the epoch" --- and regardless of whateverelse we did, that definition was probably the correct one.  We want thetime returned by time(0) to be a monotonically increasing number thatdoesn'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 ignoresleaps seconds when defining the conversion.  It probably would have beena better idea to take leap seconds into account when doing timeconversions, although this does cause other problems, such as differentUnix systems doing different things depending on when the system waslast updated (the Time standards folks only give roughly 6 monthswarning or less before adding or removing a leap second); so unless youkeep your Unix machine constantly up to date, your ctime() may return adifferent result from your neighbor's ctime(), depending on when theleap second table on your machine was last updated.  Presumably thePOSIX people decided this was too horrible, and decided to punt on theissue.   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 agood solution to this problem.  Their solution is self-consistent andwell defined, IMO.  To quote their rationale, "it is important that allconforming systems interpret "536 457 599 seconds since the Epoch" as 59seconds, 59 minutes, 23 hours 31 December 1986".  If this is the goal(and there are valid reasons for that goal --- take for example networkprotocols that send times around as "19861231235959Z") then theirsolution is the only valid one, given that when leap seconds occur isnot predictable more than a few months in advance.						- Ted-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.edu`