guy at alum.mit.edu
Fri Jul 1 18:04:18 UTC 2011
On Jul 1, 2011, at 10:12 AM, Tim Parenti wrote:
> I still think the original question of "Should TAI be added to TZ?" has not really been addressed here. I can certainly see some cases where it might be useful, provided the caveats above that it's discontinuous at leap seconds and not future-proof. But then again, all of the existing TZ zones are discontinuous (at least in some sense of the word) at leap seconds, and none of the TZ zones are future-proof, as Russia reminded us earlier this year. If we decide TAI should be added, we just have to go with applying the best data we've got into the future (i.e., TAI-UTC = 34s) until something new comes along. I think it'd be more than reasonable to expect anyone who'd actually be using TAI to understand that.
I.e., we can have a TAI zone that's not always going to properly display TAI (which isn't discontinuous at leap seconds), but that does the best it can given the limitations POSIX imposes, and it's not going to be hosed any worse by POSIX's requirements than UTC (which doesn't always go 0, 1, ..., 56, 57, 58, 59, 0, ...)?
If so, the right thing to do would probably be to add an additional flag to zic, saying whether to generate "time_t is what POSIX specifies" or "time_t is a count of atomic seconds since the Epoch"-style files, or to have zic generate two sets of compiled files, always run it with a leap seconds file, and:
for "time_t is a count of atomic seconds since the Epoch", either don't produce a TAI zone, or add a "this is TAI" flag and have it set for the TAI zone and have it mean "ignore the leap second information";
for "time_t is what POSIX specifies", use the leap seconds values to generate a special TAI zone file, and ignore them for all the other zones.
More information about the tz