Date: Wed, 29 Jun 2011 13:16:33 -0400 From: "Olson, Arthur David (NIH/NCI) [E]" <olsona@dc37a.nci.nih.gov> Message-ID: <996D816825CFEA469870126E9050D3F001C3BC1EA8@NIHMLBX11.nih.gov> One last comment (from me) about the original topic of this discussion (rather than the posix time_t discussion it devolved into)... | From: David Magda [dmagda@ee.ryerson.ca] | Sent: Wednesday, June 29, 2011 11:26 AM | Is there any reason why a TAI "time zone" ("TZ=TAI; export TZ") is not | present for those that want to ignore leap seconds? Earlier I said ... kre@munnari.oz.au said: | ps: the only problem with adding a TAI zone, is that it requires a leap | second table that's constantly updated ... but upon further reflection, and after reading Guy's most recent message, I think that comment of mine was nonsense. And further, the initial request is also pretty meaningless, TAI is not (unlike UTC) a timezone, so TZ=TAI makes precisely no sense at all. As best I understand it, TAI is just a count of seconds from its offset, and has no concept of years, months, or days, just seconds, and so attempting to use the localtime() set of functions on TAI data makes precisely no sense. The only thing (aside from using them to measure time differences, etc, at which task they work very well) that can be done with TAI in the area of absolute times is to determine the correct number of leap seconds to add, add them, producing the equivalent UTC time, and then use that with localtime(). You cannot just "ignore leap seconds" and expect to produce meaningful results. Doing this is precisely what the "right/*" set of timezone data does, so if you have a TAI second counter, that's the way to handle it, and you can get the result in any timezone that's appropriate, not by attempting to invent a meaningless TAI timezone. kre