Would it be feasible to include International Atomic Time (TAI) and/or GPS time (which differs from TAI by a fixed number of seconds) in the tz database as a time zone separate from UTC? I ask because I'm getting ready to submit at least one calendar to BCP 47 which is based on the leap-second-free TAI, and from the feedback I've gotten so far, it seems that the most widely-acceptable way to deal with the differences between TAI and UTC is to employ the tz database, if it's possible to do so. -- Thank you for your time, -- DataPacRat
On 09/14/2013 08:15 PM, DataPacRat wrote:
Would it be feasible to include International Atomic Time (TAI) and/or GPS time (which differs from TAI by a fixed number of seconds) in the tz database as a time zone separate from UTC?
It should be easy to do for the "right" subdirectory, which supports proper UTC with leap seconds, but I'm not sure how well it'd work for the "posix" subdirectory, which lacks leap seconds. To find out for sure, someone should try it and see what happens.
On Sep 14, 2013, at 9:16 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
It should be easy to do for the "right" subdirectory, which supports proper UTC with leap seconds, but I'm not sure how well it'd work for the "posix" subdirectory, which lacks leap seconds. To find out for sure, someone should try it and see what happens.
For the tz code - for example, for localtime() - there are two issues: 1) what is the *input* to the function? 2) for that input, what's its *output*? The *input* can either be a count of seconds that have elapsed since the Epoch or can be seconds-since-the-Epoch. (Yes, the snarky tone is intended.) "Seconds that have elapsed since the Epoch" is a count of the number of seconds that have elapsed between January 1, 1970, 00:00:00 UTC and the time in question; "seconds-since-the-Epoch" is: http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm "A value that approximates the number of seconds that have elapsed since 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 is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, andtm_year are all integer types: 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" I don't know whether TAI is ever represented as year/month/day/hour/minute/second. *If* TAI were to be represented in that fashion, I'd *guess* that it'd be represented by a y/m/d/h/m/s value wherein every 60 seconds the minute counter increments, every 60 minutes the hour counter increments, every 24 hours the day counter increments, and the month and year Do The Right Thing given the lengths of months and the lengths of years given the various leap year rules. Leap seconds wouldn't matter. Converting "seconds since the Epoch" to that format involves some divisions to get days, and then doing the right stuff to get month and year; leap seconds aren't involved. I don't know how to convert "seconds-since-the-Epoch" to TAI, and I'm not sure it's even possible; if it is, the code would, as far as I know, need to do *something* to cope with leap seconds, and would thus need *some* information about leap seconds, which is absent from the "posix" subdirectory. ITU-R Recommendation ITU-R TF.460-6: http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pd... seems to represent UTC as year/month/day/hour/minute/second, with "second" allowed to be bigger than 59 and allowed to go from 58 to 0. With the "right" subdirectory, the TZ code will convert "seconds that have elapsed since the Epoch" can be converte to UTC represented in that fashion; with the "posix" subdirectory, the TZ code will convert "seconds-since-the-Epoch" (which does weird things during leap seconds - i.e., it doesn't count up by 1 every second!) to UTC (with leap seconds not being converted "correctly", given that the "seconds-since-the-Epoch" value for a leap second and the second after it are the same).
On Sat 2013-09-14T23:59:53 -0700, Guy Harris hath writ:
The *input* can either be a count of seconds that have elapsed since the Epoch or can be seconds-since-the-Epoch. (Yes, the snarky tone is intended.)
I hesitantly point out that due to variations in national legislation phrases like the number of "seconds that have elapsed since the Epoch" is subject to variation between jurisdictions http://www.ucolick.org/~sla/leapsecs/epochtime.html The distinction between the "right" and POSIX flavors of tz corresponds to the two extremes. The "right" flavor counts the number of second markers actually used in radio broadcast time signals (effectively mean solar seconds before 1972 and atomic seconds after). The POSIX flavor effectively counts mean solar seconds in order that it can have 86400 in a civil day (which so far is mean solar). So phrases like "seconds that have been broadcast according to international radio regulations" may be useful for clarity. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Sep 15, 2013, at 5:03 AM, Steve Allen <sla@ucolick.org> wrote:
So phrases like "seconds that have been broadcast according to international radio regulations"
...and "mean solar seconds", i.e. do a global search and replace of "seconds since the Epoch" with "*mean solar* seconds since the Epoch" (and the same for non-English-language documents).
may be useful for clarity.
On Sep 14, 2013, at 11:59 PM, Guy Harris <guy@alum.mit.edu> wrote:
I don't know how to convert "seconds-since-the-Epoch" to TAI
Add in the number of positive leap seconds, and subtract out the number of negative leap seconds, that have elapsed or that we *know* will elapse between the Epoch and the time in question. (Or am I missing something there.) (No, this won't work if the "seconds-since-the-Epoch" value is far enough in the future and if the IERS ends up announcing an additional leap second or seconds before that point, but, well, *nothing*, other than a perfect lower-case-"o" oracle, will work in that case.) This requires having the values from the "leapseconds" file around, but using them differently from the way the tz code uses them now.
On Sun, Sep 15, 2013 at 12:16 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 09/14/2013 08:15 PM, DataPacRat wrote:
Would it be feasible to include International Atomic Time (TAI) and/or GPS time (which differs from TAI by a fixed number of seconds) in the tz database as a time zone separate from UTC?
It should be easy to do for the "right" subdirectory, which supports proper UTC with leap seconds, but I'm not sure how well it'd work for the "posix" subdirectory, which lacks leap seconds. To find out for sure, someone should try it and see what happens.
I'm afraid that I don't yet know enough about the subdirectories to comment, but I do know that the standard for POSIX time includes leap seconds - adding one at the appropriate :60 when one's added, or jumping from :58 to :00 should one ever be subtracted. A variant which ignores leap seconds and matches TAI is "non-conforming". (Handiest reference: first sentence of https://en.wikipedia.org/wiki/Unix_time#TAI-based_variant .) Thank you for your time, -- DataPacRat "Then again, I could be wrong."
On Sep 15, 2013, at 12:36 AM, DataPacRat <datapacrat@gmail.com> wrote:
On Sun, Sep 15, 2013 at 12:16 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 09/14/2013 08:15 PM, DataPacRat wrote:
Would it be feasible to include International Atomic Time (TAI) and/or GPS time (which differs from TAI by a fixed number of seconds) in the tz database as a time zone separate from UTC?
It should be easy to do for the "right" subdirectory, which supports proper UTC with leap seconds, but I'm not sure how well it'd work for the "posix" subdirectory, which lacks leap seconds. To find out for sure, someone should try it and see what happens.
I'm afraid that I don't yet know enough about the subdirectories to comment, but I do know that the standard for POSIX time includes leap seconds - adding one at the appropriate :60 when one's added, or jumping from :58 to :00 should one ever be subtracted.
That's "seconds-since-the-Epoch" from my e-mail. It "includes" leap seconds in the sense of "trying its best to hide their existence" - the formula for "seconds-since-the-Epoch" in the POSIX standard is 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 which gives the same value 2012/06/30 23:59:60: 60 + 59*60 + 23*3600 + 182*86400 + 42*31536000 + 10*86400 - 1*86400 + 1*86400 = 1341187200 and 2012/07/01 00:00:00: 0 + 0*60 + 0*3600 + 183*86400 + 42*31536000 + 10*86400 - 1*86400 + 1*86400 = 1341187200 which means that, when a leap second is added, the POSIX clock *doesn't* advance for that second (whether the clock just stops for a second or is slowed down until the second is lost).
A variant which ignores leap seconds and matches TAI is "non-conforming".
That's "seconds that have elapsed since the Epoch", which is perhaps better described as "counting seconds that elapse, including leap seconds", so what it ignores is the distinction between leap seconds and ordinary seconds. The TZ code is capable of handling "seconds that have elapsed since the Epoch" in the sense that it can convert those values to the corresponding UTC labels, even if that means, for example, setting tm_sec to 60. That's done if the "leapseconds" source file is used by zic (with the -L flag); in systems that have separate "right" and "posix" subdirectories for sic-compiled files, "right" contains files compiled with "-L leapseconds" and "posix" contains files compiled without "-L leapseconds". When used with files compiled without "-L leapseconds", the TZ code's gmtime() will turn "seconds-since-the-Epoch" values into "struct tm" values corresponding to one of the UTC labels for the "seconds-since-the-Epoch" value in question. With positive leap seconds, there are two (or more) UTC labels for some "seconds-since-the-Epoch" values, and it'll return the label that has tm_sec < 60; with negative leap seconds, there may be some "seconds-since-the-Epoch" values that are invalid, and I don't know what it'll return for them.
participants (4)
-
DataPacRat -
Guy Harris -
Paul Eggert -
Steve Allen