On 2014-01-18 03:07 PM, Eric R. Smith wrote:
On 2014-01-18 12:02, Joseph Gwinn wrote:
[POSIX time]
...
It's defined as a transformation of a broken-down UTC timestamp, not
(despite its name) as a count of seconds since some instant.
No. If your poke around into how time is used, you will discover that
what is stored in the cound of seconds since the Epoch. Broken-down
time is used only when there is a human to be humored.
A count of "non-leap seconds" since the Epoch. That is a crucial
difference, and it's (IMHO) the root cause of many leap second problems.
Its an *uncompensated-for-leap-seconds* Gregorian calendar counting
scheme. I've never seen it described that way, but that's what it is.
time_t presents itself as "elapsed time", and is frequently used that
way, but it is not elapsed time in the usual meaning of the term (i.e.
number of elapsed SI seconds).
It's frustrating, because POSIX comes really close to providing both of
the aspects of time (elapsed duration and civil time) that applications
require. It wisely provides a human readable time structure (struct tm),
and functions to convert this to and from time_t,
Its not just human readable - its a representation of time_t in YY-MM-DD
hh:mm:ss form.
but then requires
time_t to satisfy a simple formula so that the conversion between struct
tm and time_t is fixed.
gmtime() performs a "break-down" of time_t to YY-MM-DD hh:mm:ss. Its the
inverse of the formula defined in 4.15 Seconds Since the Epoch -
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year−70)*31536000 + ((tm_year−69)/4)*86400 −
((tm_year−1)/100)*86400 + ((tm_year+299)/400)*86400
This is an *uncompensated-for-leap-seconds* Gregorian calendar counting
scheme with an artificially imposed "1970" ("the Epoch") "origin". I
like to call it the 1970 *barrier*.
If it just dropped that formula and required use
of library functions to convert time_t to/from struct tm then it would
at least be possible to implement time_t as a true count of elapsed
seconds on a POSIX compliant system.
gmtime() will "do the right thing" (for dates after 1972) if you adjust
time_t by Leap-Seconds-in-effect.
It gets more squirrelly when doing localtime()....
But, CAUTION - not all implementations of gmtime() are equally good.
I've compiled and tested many versions from the open-source community
and many have smoking gun errors. Outright bugs don't help confidence in
consistent implementation and contribute to the confusion.
Alas, there are difficulties with this too -- leap seconds are
unpredictable, and interchange of file timestamps between POSIX systems
becomes harder. Maybe the way forward would be to introduce a new
"elapsedtime_t" type that really does count seconds since the Epoch (to
be used in any applications that require duration) and to deprecate
arithmetic on time_t values (which is problematic around leap seconds).
Yes, generally. Getting ANSI c and POSIX standards bodies to change
their ways is an uphill battle. Convincing some parts of the
time-keeping community that uses POSIX and derivatives might be more
feasible if a clear specification existed.
-Brooks
Eric
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
