[tz] TAI as a time zone?

Guy Harris guy at alum.mit.edu
Sun Sep 15 06:59:53 UTC 2013

On Sep 14, 2013, at 9:16 PM, Paul Eggert <eggert at 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:


"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:


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).

More information about the tz mailing list