"Remove leap seconds from UTC" is clearly absurd, and I'm baffled that ACM would lend its good name to such a notion. UTC is defined as atomic time plus leap seconds, for good and sufficient reasons. And as was pointed out, TAI already exists for those who want atomic time plain, without leap seconds. The quoted Linux description is even more bizarre, since "TIA .. includes leap seconds" is a complicated and misleading way of saying "UTC". I wonder if this requests amounts to "Posix should be extended to provide an interface to TAI". If so, that certainly makes sense. Is that something tzdata can do, or does it have to be done in some other layer? paul On Jun 29, 2011, at 1:16 PM, Olson, Arthur David (NIH/NCI) [E] wrote:

I'm forwarding this message from David Magda, who is not on the time zone mailing list; those of you who are on the list, please direct replies appropriately.

--ado ________________________________________ From: David Magda [dmagda@ee.ryerson.ca] Sent: Wednesday, June 29, 2011 11:26 AM To: tz@lecserver.nci.nih.gov Subject: TAI zone?

[Not a subscriber, so please CC.]

Hello,

There's been some discussion of removing leap seconds from UTC, as some people need/want a more predictable and deterministic time scale. [1] Given that International Atomic Time [2] exists, there doesn't seem to be an easy way to reference it.

Is there any reason why a TAI "time zone" ("TZ=TAI; export TZ") is not present for those that want to ignore leap seconds? I noticed that some Linux distributions have a "right/" directory [3] to deal with this in some way:

...

Two different versions are provided: - The "posix" version is based on the Coordinated Universal Time (UTC). - The "right" version is based on the International Atomic Time (TAI), and it includes the leap seconds. [...]

- TZDIR=/usr/share/zoneinfo/posix TZ=Europe/Paris on a system with hardware clock set to UTC. - TZDIR=/usr/share/zoneinfo/right TZ=Europe/Paris on a system with hardware clock set to TAI.

Regards, David

[1] http://cacm.acm.org/magazines/2011/5/107699-the-one-second-war/fulltext [2] http://en.wikipedia.org/wiki/International_Atomic_Time [3] /usr/share/doc/tzdata/README.Debian

Date: Wed, 29 Jun 2011 14:27:53 -0400 From: Paul Koning <paul_koning@Dell.com> Message-ID: <1ED832E5-A4DA-4BCC-8273-BA2715F12017@dell.com> | I wonder if this requests amounts to "Posix should be extended to | provide an interface to TAI". If so, that certainly makes sense. | Is that something tzdata can do, or does it have to be done in some | other layer? It is a mess. Do remember that POSIX time is really neither UTC nor TAI. That is, it acts like TAI, but the value is the same as it would be if it were UTC. POSIX manages this by making seconds be variable length objects, so there's always exactly 31536000 of them in a year (31622400 in leap years). That is, given that the time was (a minute and a bit ago as I type this) 1309392000 seconds past the unix epoch (Jan 1, 1970 00:00:00), we can calculate the date by simple arithmetic, 1309392000/31536000 == 41 (rounded down) so 41 years have passed, which means 10 leap years (and yes, I know that in reality this would take more work to evaluate, but happens to be right in this case just doing 41/4), so 10 extra days to allow for, or 864000 extra seconds. 41 * 31536000 + 864000 == 1293840000 So, we must be 1309392000 - 1293840000 seconds into 1970+41 (2011). That is, 15552000 seconds into 2011. 15552000/86400 == 180, so 180 days have passed (and 180*86400 == 15552000 so exactly 180 days had passed - and yes, by co-incidence, it was exactly UTC midnight when I looked at the time value - or close enough that I just subtracted away the extra 100 or so seconds for the purposes of this e-mail). 180-31-28-31-30-31 == 29 That's Jan Feb (non-leap) Mar Apr May, so 29 days have passed in June, so it must be (have been 10 mins ago now) midnight on June 30, 2011, UTC. And yes, that's what it was. Now notice the notable lack of any reference to any table of leap seconds in the calculations above. So, we have something that looks like TAI. Except the TAI time would be 14 (?) seconds different than this, so it isn't TAI either - instead we have the wonderful POSIX seconds. In order to make this work, every time there's a leap second added, POSIX seconds all have to get a little larger, and if there was ever a leap second removed, POSIX seconds would all have to get a little smaller... This is a bizarre definition of time from any physics, or astronomy sense, but happens to be almost ideal for everything else (regular time measuring).. It just fits most people's expectations of how time works, where esoteric stuff like leap seconds can be just ignored. kre ps: the only problem with adding a TAI zone, is that it requires a leap second table that's constantly updated - the nice thing about POSIX time is that (summer time complications aside) no external data is required to convert a unix time_t into a human clock value, and vice versa, so as long as the summer time rules don't change (or don't exist) - which actually covers most of the world, most of the time, nothing ever needs to be periodically updated.

On Jun 29, 2011, at 9:01 PM, Paul Koning wrote:

On Jun 29, 2011, at 8:22 PM, Robert Elz wrote:

...

Date: Wed, 29 Jun 2011 14:27:53 -0400 From: Paul Koning <paul_koning@Dell.com> Message-ID: <1ED832E5-A4DA-4BCC-8273-BA2715F12017@dell.com>

| I wonder if this requests amounts to "Posix should be extended to | provide an interface to TAI". If so, that certainly makes sense. | Is that something tzdata can do, or does it have to be done in some | other layer?

It is a mess. Do remember that POSIX time is really neither UTC nor TAI. That is, it acts like TAI, but the value is the same as it would be if it were UTC. POSIX manages this by making seconds be variable length objects, so there's always exactly 31536000 of them in a year (31622400 in leap years).

Wow. Are you sure of that? ...

Never mind, I guess my leg just got pulled. paul

On Jun 29, 2011, at 6:20 PM, Paul Koning wrote:

Never mind, I guess my leg just got pulled.

For the full story, read section 4.15 "Seconds Since the Epoch" of http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html and http://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html and http://pubs.opengroup.org/onlinepubs/9699919799/functions/localtime.html and http://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html and section A.4.15 "Seconds Since the Epoch" of http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html In a sane world: 1) time() would return a value that tries its hardest to be a count of the number of seconds that have elapsed since 1970-01-01 00:00:00 UTC (meaning it doesn't stop during a positive leap second, nor does it leap ahead when a negative leap second occurs); 2) gmtime() would convert that value to the appropriate set of numbers for the UTC label for that instant in time, including the seconds value being "60" or "61" or whatever's involved in properly handling leap seconds; 3) localtime() would convert that value to the appropriate set of numbers for the local time label for that instant in time, including the previous plus time zone conversion; 4) mktime() would convert the other way as best as can be done given any cases where multiple instances of time have the same labels. At least as I read Annex I of http://www.cl.cam.ac.uk/~mgk25/volatile/ITU-R-TF.460-4.pdf it says that TAI is, ultimately, a counter that ticks once per second: B. International Atomic Time (TAI) The international reference scale of atomic time (TAI), based on the second (SI), as realized at sea level, is formed by the Bureau international des poids et mesures (BIPM) on the basis of clock data supplied by cooper- ating establishments. It is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 (adopted by the CGPM 1971). (which sounds like "seconds since the TAI Epoch", where the TAI Epoch is the beginning of 1958-01-01 in, presumably, Greenwich in the UK). I'm not quite sure what it's saying about UTC: C. Coordinated Universal Time (UTC) UTC is the time-scale maintained by the BIPM, with assistance from the International Earth Rotation Service (IERS), which forms the basis of a coordinated dissemination of standard frequencies and time signals. It corresponds exactly in rate with TAI but differs from it by an integral number of seconds. The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leap-seconds) to unsure approximate agreement with UT1. "Corresponds exactly in rate with TAI" sounds like "ticks once per second". I'm not sure what "the UTC scale" in "The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leap-seconds) to unsure approximate agreement with UT1." means; does it mean that the "integral number of seconds" between UTC and TAI varies over time (which means UTC is *not* a counter that ticks once per second), or does it mean that if you attach date/hour/minute/second labels to values on the UTC scale, they don't always go from, say, {date}/23/59/59 to {date+1}/00/00/00 - they might jump from {date}/23/59/58 to {date+1}/00/00/00, or from {date}/23/59/59 to {date}/23/59/60 to {date+1}/00/00/00?

Date: Wed, 29 Jun 2011 21:01:27 -0400 From: Paul Koning <paul_koning@Dell.com> Message-ID: <B30EB3C3-48E8-47C2-BAFB-0D8916E3A579@dell.com> | Wow. Are you sure of that? Pretty sure, yes (no leg pulling involved). You can google "posix time_t" yourself if you like (there's plenty out there on this topic). | If true, that is incredibly stupid. That all depends upon your point of view. | It clearly isn't part of the charter of any such standard to redefine | the metric system. Which isn't what they did, they didn't attempt to redefine TAI or UTC (or even GMT) - they just define what a posix time_t value contains, which is clearly something that is within its charter. Whether you agree with the result or not, there's no doubt of that. | Also, even if it does pretend to define it that way, it isn't | implemented that way in the real world. It certainly is, one way or another - that's exactly what we deal with here. The "linux" "right" set of data isn't a linux thing at all (of course), it came from here (the tz project), and was an early attempt to do things correctly (that's "right" as opposed to the "wrong" we actually have, not right vs left or something). But while it was right (or correct) in some sense of the definition of time, it wasn't right according to the values in a time_t, which are really difficult to alter, as time_t values are stored in all kind of unchangeable places using the original definition (which is really that there are 86400 exactly every day). We still keep it around, for people who really need TAI time (or genuine UTC), that just happens to not be POSIX, so almost no-one actually uses it. The quote from the linux doc

- The "right" version is based on the International Atomic Time (TAI), and it includes the leap seconds. [...]

is/was supposed to just mean that you have a hardware clock that's ticking TAI (and so doesn't get adjusted for leap seconds), and then the "right" data makes the leap second adjustment so when the data is converted to human form we get the expected (UTC) result that matches the clock on the wall, and from the radio etc. | I have never seen a system that uses nonstandard seconds, I bet you have, as it is what just about everyone uses in practice. The implementation doesn't necessarily use stretchy seconds (though that's what BSD based unix systems do - they use the adjusttime() sys call whenever the system clock is different from the correct time_t value (usually determined using the NTP porotocol), which causes the internal tick rate to alter just a little until things are back in alignment). Other systems just alter the time value occasionally. (After all, no-one has perfect hardware counters, they all drift, except those few of us (or of you I should say) who have genuine atomic clocks.) Everything else has seconds that don't match TAI or UTC reality anyway, and so constantly need corrections, one way or another. The occasional leap second correction is typically more minor than the correction needed due to hardware imperfections. If you have ever seen a system (other than one of those very expensive atomic clocks) that genuinely ticks fixed length seconds, then more power to you. All the rest of us live with stretchy seconds, all the time, and we don't really suffer for it. And maybe that is UT1 we're using, I haven't looked at its definition to know if POSIX time is really it or not. | and I certainly will not tolerate such a system in any place where | I have anything to do with its design. Feel free to do what you like, but if you're ever exchanging time data with anyone else, and you're doing it in some second-counting format, posix time_t's are almost certainly what you're getting. kre

On Jun 29, 2011, at 22:46, Guy Harris wrote:

So who was the person who wrote, in the current POSIX rationale:

A little of bit of history from a 2003 post to the "leapsec" listserv: http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html

Am 30.06.2011 04:46, schrieb Guy Harris:

On Jun 29, 2011, at 6:53 PM, Robert Elz wrote:

...

is/was supposed to just mean that you have a hardware clock that's ticking TAI (and so doesn't get adjusted for leap seconds), and then the "right" data makes the leap second adjustment so when the data is converted to human form we get the expected (UTC) result that matches the clock on the wall,

In Germany (at least) a lot of private clock use the dcf77 signal what is the official time signal for germany. And that honors leapseconds, sommertime etc. It is true that you can not get UTC clocks this is reasonable since most people expect there clock to have localtime.

Most of the clocks-on-the-wall probably don't give results that match UTC, as they probably always go, at the end of the day-in-Greenwich, from 58 seconds to 59 seconds to 00 seconds, leap seconds notwithstanding. My watch also knows nothing of leap seconds; I suspect almost nobody's watch does.

(My work computer, and my home computer, and my mobile phone are another matter, given that they're all running BSD-based UN*X systems. At least on one of them, the Olson database is built without leap seconds:

$ file /usr/share/zoneinfo/America/Los_Angeles /usr/share/zoneinfo/America/Los_Angeles: timezone data, old version, 4 gmt time flags, 4 std time flags, no leap seconds, 185 transition times, 4 abbreviation chars

and I think that's the case with all of them. My work and home computers sync up against NTP servers, and NTP actually cares about leap seconds, so, while the clock on the menu bar won't go from XX:59:59 to XX:59:60 to YY:00:00 over a positive leap second (at the end of the year, that'd probably be 15:59:59 to 15:59:60 to 16:00:00 out here in California), it'll probably end up in effect getting adjusted for leap seconds.)

So who was the person who wrote, in the current POSIX rationale:

Most systems' notion of "time" is that of a continuously increasing value, so this value should increase even during leap seconds. However, not only do most systems not keep track of leap seconds, but most systems are probably not synchronized to any standard time reference. Therefore, it is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.

A clock that's implemented as a hardware counter and a periodic interrupt will, *BY DEFAULT*, "increase even during leap seconds", without having to "keep track of leap seconds". Was the person who wrote that unaware of that, or are they concerned about, say, machines with hardware clocks that have year/month/day/hour/minute/second or something "helpful" such as that?

"Most systems are probably not synchronized to any standard time reference" would be a more serious reason than "most systems [do] not keep track of leap seconds" not to "require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch", as per your note that "The occasional leap second correction is typically more minor than the correction needed due to hardware imperfections."

In practice, I suspect that time_t doesn't explicitly stop across positive leap seconds or jump ahead across negative leap seconds, but, on most systems, might be adjusted by NTP etc. so that, in the sufficiently long run (which is probably at most only a few minutes) it has the same effect. A system really using an atomic clock might well really truly tick time_t once per second without any other changes, so that, if the Olson database lacks leap second information, "date -u" command won't print out the correct UTC label for the time, given that a POSIX-conformant system must "interpret "536457599 seconds since the Epoch" as 59 seconds, 59 minutes, 23 hours 31 December 1986".

i agree on that the posix people have the wrong impression (maybe coming for a country that does not have a propper (free) time signal). E.g. most dsl routers use ntp to sync themself with the net and mots people simple use that routers to get a propper time (most without realizing it, (author ?)). It is reasonable to assume that time is monotonic but what resolution ? for day by day living 1s is ok. Changing the length of a second is a technical fix that means a change below the resolution that is needed. I can understand WHY some people would like to have thinks like TAI but that technical requirement simply does not fix the really in this universe. just my 2 cents, wh ps: we have wallclocks that show utc time but they do not use dcf77 so much to reality :) @guy harris thx for digging for that references

Am 01.07.2011 12:35, schrieb Guy Harris:

On Jun 30, 2011, at 2:02 AM, walter harms wrote:

...

In Germany (at least) a lot of private clock use the dcf77 signal what is the official time signal for germany. And that honors leapseconds, sommertime etc. It is true that you can not get UTC clocks this is reasonable since most people expect there clock to have localtime.

"matches the clock on the wall" means "modulo the time zone you're in", i.e. the hour might not match UTC, but the minutes and seconds do.

So what do those clocks display in the second counter during a positive leap second? A value > 59?

I can only assume that they "stop" for one second. my ntpd says (normal use) "timecode="\x02D:01.07.11;T:5;U:13.21.36; S \x03"," and refclock_status="DST; TIME CODE; (LEAP INDICATION)", If i produces would like a simple solution for a wall clock i (!) would ignore anything > 59s, no comsumer would notice, that an update is missing for 1sec. re, wh

Paul Koning said:

...

It is a mess. Do remember that POSIX time is really neither UTC nor TAI. That is, it acts like TAI, but the value is the same as it would be if it were UTC. POSIX manages this by making seconds be variable length objects, so there's always exactly 31536000 of them in a year (31622400 in leap years).

Wow. Are you sure of that? If true, that is incredibly stupid. It clearly isn't part of the charter of any such standard to redefine the metric system.

Also, even if it does pretend to define it that way, it isn't implemented that way in the real world. I have never seen a system that uses nonstandard seconds, and I certainly will not tolerate such a system in any place where I have anything to do with its design.

Let me try an explain this. [I've just given a paper explaining this to lawyers, so I should be able to do it to computer programmers.] The SI second is defined in terms of vibrations of the caesium atom. Let's imagine a counter that ticks exactly once every SI second. This counter was started at the beginning of 1958 and has ticked steadily ever since. Now let's feed this counter through the normal date-time decoding process: seconds = N % 60 minutes = (N / 60) % 60 hours = (N / 3600) % 24 daynumber = N / 86400 { year, month, day } = Gregorian_decode (daynumber) This is the TAI clock. It ticks steadily and regularly, always with 60 seconds to the minute, 60 minutes to the hour, 24 hours to the day, 28/29/30/31 days to the month, 12 months to the year. Right now it's saying 2011-07-01 11:28:45. Note that TAI is a clock, not a count of seconds. Now imagine a second clock. This also ticks once per second. Right now it's 34 seconds behind the TAI clock, so it is saying 2011-07-01 11:28:11. This clock has 60 minutes to the hour, 24 hours to the day, 28/29/30/31 days to the month, and 12 months to the year, but while it usually has 60 seconds to the minute, it sometimes has 59 or 61 - these minutes are always the last minute of a month. So at the end of this year it could tick any of: 2011-12-31 23:59:56 2011-12-31 23:59:56 2011-12-31 23:59:56 2011-12-31 23:59:57 2011-12-31 23:59:57 2011-12-31 23:59:57 2011-12-31 23:59:58 2011-12-31 23:59:58 2011-12-31 23:59:58 2012-01-01 00:00:00 2011-12-31 23:59:59 2011-12-31 23:59:59 2012-01-01 00:00:01 2012-01-01 00:00:00 2011-12-31 23:59:60 2012-01-01 00:00:02 2012-01-01 00:00:01 2012-01-01 00:00:00 2012-01-01 00:00:03 2012-01-01 00:00:02 2012-01-01 00:00:01 2012-01-01 00:00:04 2012-01-01 00:00:03 2012-01-01 00:00:02 (and we don't yet know which of them it will be). This is the UTC clock. Note that TAI-UTC is always an integer number of seconds. How do we know whether a minute is 59, 60, or 61 seconds on the UTC clock? That comes below. Now, we live on a lump of rock and iron that spins. We're surrounded by stars a long way away that provide a workable reference frame. Because we go round the sun once a year, it's useful to construct a second reference frame that spins, relative to the first, once a year. The angle between a point on the earth and that second reference frame then goes through 360 degrees about every 86400 seconds. If we make the "point" be somewhere on the prime meridian, count the whole rotations and call them days, and convert the angle to a time in the normal way (15 degrees = 1 hour, 15 minutes of arc = 1 minute of time, etc.) then we get another clock. This is the UT clock (the difference between GMT, UT, UT0, UT1, UT2, UT1R, and UT2R is not relevant for this discussion). The value of the SI second was chosen so that the UT clock changes at about one UT second per SI second. However, because the earth's rotation isn't uniform the rate isn't exact or constant. This means that the value of TAI-UTC isn't constant. Instead, at the moment, it is increasing at an average of between 0.5 and 1 second per year. And now we can explain UTC. UTC picks whether to have a minute that is 59, 60, or 61 seconds long by chosing the one that ensures that |UTC-UT1| < 0.9s. The history of and predictions of the earth's rotation are used to make the choice - so far we've never had a 59 second minute but have had several 61 second minutes. Now POSIX. The value of time_t is defined as ticking once per (SI) second, keeping in sync with UTC, but ignoring leap seconds. This definitions is a (slight) lie. What actually happens is that the counter increases once per second most of the time, but at the end of a month: - if the last minute has 60 seconds, it increases by 1 from 23:59:59 to 00:00:00; - if the last minute has 59 seconds, it increases by 2 from 23:59:58 to 00:00:00 (a period of 1 second); - if the last minute has 61 seconds, it increases by 1 from 23:59:59 to 23:59:60, then does not change from 23:59:60 to 00:00:00 (so increasing by only 1 in 2 seconds). Actual computer systems may follow this. Or they may alter the speed of their internal clock to slew them back into sync with the value of time_t, just as they do when they discover an error in their internal clock. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On Jul 1, 2011, at 07:59, Clive D.W. Feather wrote:

Let me try an explain this. [I've just given a paper explaining this to lawyers, so I should be able to do it to computer programmers.]

Is there a copy of this paper online somewhere? Every so often I have to explain these esoteric time details to people, and a reference to point to would be handy.

On Jul 1, 2011, at 4:59 AM, Clive D.W. Feather wrote:

The SI second is defined in terms of vibrations of the caesium atom. Let's imagine a counter that ticks exactly once every SI second. This counter was started at the beginning of 1958 and has ticked steadily ever since.

Now let's feed this counter through the normal date-time decoding process: seconds = N % 60 minutes = (N / 60) % 60 hours = (N / 3600) % 24 daynumber = N / 86400 { year, month, day } = Gregorian_decode (daynumber) This is the TAI clock. It ticks steadily and regularly, always with 60 seconds to the minute, 60 minutes to the hour, 24 hours to the day, 28/29/30/31 days to the month, 12 months to the year. Right now it's saying 2011-07-01 11:28:45. Note that TAI is a clock, not a count of seconds.

(...if "clock" includes not only HH:MM:SS but also a date.)

Now imagine a second clock. This also ticks once per second. Right now it's 34 seconds behind the TAI clock, so it is saying 2011-07-01 11:28:11. This clock has 60 minutes to the hour, 24 hours to the day, 28/29/30/31 days to the month, and 12 months to the year, but while it usually has 60 seconds to the minute, it sometimes has 59 or 61 - these minutes are always the last minute of a month. So at the end of this year it could tick any of:

2011-12-31 23:59:56 2011-12-31 23:59:56 2011-12-31 23:59:56 2011-12-31 23:59:57 2011-12-31 23:59:57 2011-12-31 23:59:57 2011-12-31 23:59:58 2011-12-31 23:59:58 2011-12-31 23:59:58 2012-01-01 00:00:00 2011-12-31 23:59:59 2011-12-31 23:59:59 2012-01-01 00:00:01 2012-01-01 00:00:00 2011-12-31 23:59:60 2012-01-01 00:00:02 2012-01-01 00:00:01 2012-01-01 00:00:00 2012-01-01 00:00:03 2012-01-01 00:00:02 2012-01-01 00:00:01 2012-01-01 00:00:04 2012-01-01 00:00:03 2012-01-01 00:00:02

(and we don't yet know which of them it will be). This is the UTC clock. Note that TAI-UTC is always an integer number of seconds.

(And one could make a UTC clock out of the SI-second counter with the Olson code and an Olson database built with the leap seconds database, as long as you keep the copy of the Olson database up-to-date with leap-second updates.) So "34 seconds behind the TAI clock" says nothing about any counters of SI seconds; it says something about what the TAI and UTC clocks display.

Now POSIX. The value of time_t is defined as ticking once per (SI) second, keeping in sync with UTC, but ignoring leap seconds. This definitions is a (slight) lie.

What "4.15 Seconds Since the Epoch" says 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, and tm_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 which means that 2008-12-31 23:59:60 and 2009-01-01 00:00:00 would map to the same time_t value. The rationale for that second explicitly says that: A.4.15 Seconds Since the Epoch Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences. Broken-down POSIX time is therefore not necessarily UTC, despite its appearance.

What actually happens is that the counter increases once per second most of the time, but at the end of a month: - if the last minute has 60 seconds, it increases by 1 from 23:59:59 to 00:00:00; - if the last minute has 59 seconds, it increases by 2 from 23:59:58 to 00:00:00 (a period of 1 second); - if the last minute has 61 seconds, it increases by 1 from 23:59:59 to 23:59:60, then does not change from 23:59:60 to 00:00:00 (so increasing by only 1 in 2 seconds).

...which matches "4.15 Seconds Since the Epoch".

Actual computer systems may follow this. Or they may alter the speed of their internal clock to slew them back into sync with the value of time_t, just as they do when they discover an error in their internal clock.

...or they may fail to do either, and thus, in practice, violate POSIX. I suspect that, these days, NTP is used enough that they do arrange that time_t not tick exactly once per SI second (yeah, one could view that as "NTP is not only used to *correct* clock drift, it's also used to *cause* clock drift as required by POSIX"). And, yes, that means that POSIX requires that if your OS's implementation of time() ends up driven by an atomic clock, it would either have to read a leap-second database to know when to do something other than increment the time_t counter when the atomic clock says "ping", or would have to have the atomic-clock-driven counter not be returned by time() but be adjusted with a leap-second database before being returned by time(), or would have to otherwise take leap second information into account. It also means that if your really want to know how many seconds elapse between two events, don't use POSIX time_t.

On 07/01/11 09:43, Guy Harris wrote:

It also means that if your really want to know how many seconds elapse between two events, don't use POSIX time_t.

... or more precisely, don't use POSIX clock_gettime (CLOCK_REALTIME, ...). POSIX apps are supposed to use clock_gettime (CLOCK_MONOTONIC, ...) if they want to count elapsed time. This POSIX feature is needed for reasons other than leap seconds, for example, if your sysadmin (or NTP subsystem) changes the real-time clock, CLOCK_MONOTONIC is supposed to be immune to that. This is a tricky business, though, since NTP does adjust the the clock *frequency*, and CLOCK_MONOTONIC is *not* supposed to be immune to *that*. If you want your elapsed-time measurements to be more reliable in the presence of clock-frequency adjustments, you need something fancier, e.g., GNU/Linux's CLOCK_MONOTONIC_RAW.

On Jul 1, 2011, at 1:16 PM, Guy Harris wrote:

On Jul 1, 2011, at 10:08 AM, Paul Eggert wrote:

...

This is a tricky business, though, since NTP does adjust the the clock *frequency*, and CLOCK_MONOTONIC is *not* supposed to be immune to *that*. If you want your elapsed-time measurements to be more reliable in the presence of clock-frequency adjustments, you need something fancier, e.g., GNU/Linux's CLOCK_MONOTONIC_RAW.

If you care *that* much, you need something fancier, e.g. an atomic clock. :-) I seem to remember some news article in the past year or so indicating that there might be some new type of atomic clock coming out that would be less expensive, but I can't seem to find it with some simple Googling.

There was a new clock that's particularly compact (an inch or so max dimension). It wasn't clear just how it works, but it sounded like it's comparable in stability to a rubidium clock. In the meantime, I think the cheapest atomic time source is a GPS box. paul

Please remove me from the mailing list. Too much email concerning this issue. I would suggest meeting in a common virtual space and having a live discussion, rather then "replying all" when continuing to have this conversation. Thank You, Terrence Barrett From: David Magda <dmagda@ee.ryerson.ca> To: <tz@lecserver.nci.nih.gov> Cc: Paul Koning <paul_koning@Dell.com>, Guy Harris <guy@alum.mit.edu> Date: 07/01/2011 01:29 PM Subject: Re: TAI zone? On Jul 1, 2011, at 13:21, Paul Koning wrote:

On Jul 1, 2011, at 1:16 PM, Guy Harris wrote:

...

If you care *that* much, you need something fancier, e.g. an atomic

clock. :-) I seem to remember some news article in the past year or so indicating that there might be some new type of atomic clock coming out that would be less expensive, but I can't seem to find it with some simple Googling.

There was a new clock that's particularly compact (an inch or so max

dimension). It wasn't clear just how it works, but it sounded like it's comparable in stability to a rubidium clock.

In the meantime, I think the cheapest atomic time source is a GPS box.

Probably related to this:

Now an atomic clock-on-a-chip is available that is the result of 10 years of government-funded research and development. The chip is not cheap — $1,500 — but it costs less than conventional atomic clocks and the price is sure to go down as manufacturing gears up to meet demand from military applications.

http://science.slashdot.org/story/11/05/11/1745213/ ------------------------------------------------------------ The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of the company. ------------------------------------------------------------

On Jul 1, 2011, at 13:41, Paul Koning wrote:

Interesting article. It says that the active medium is cesium, but then mentions a resonant frequency that is not the one used in the definition of the second. So either the author is very confused and pulled a random number out of the air, or we're dealing with a different resonance than the standard one. In that case, it is entirely unclear how stable it is. It might be similar to the one used in the definition of the second, or it might be very different (like rubidium, or worse).

The chip in question: http://tinyurl.com/67znzrt http://www.symmetricom.com/products/frequency-references/chip-scale-atomic-c... http://www.jackson-labs.com/index.php/products/csac http://www.google.com/search?q=CSAC+SA.45s

On Fri, Jul 01, 2011 at 09:43:49AM -0700, Guy Harris wrote:

...

Actual computer systems may follow this. Or they may alter the speed of their internal clock to slew them back into sync with the value of time_t, just as they do when they discover an error in their internal clock.

...or they may fail to do either, and thus, in practice, violate POSIX. I suspect that, these days, NTP is used enough that they do arrange that time_t not tick exactly once per SI second (yeah, one could view that as "NTP is not only used to *correct* clock drift, it's also used to *cause* clock drift as required by POSIX").

NTP doesn't have a table of leap seconds (or even much knowledge about them ahead of time), so the clock isn't slewed or modified ahead of a leap second insertion. Some computers have (non-POSIX) interfaces to allow NTP to either insert a second or pause the clock for a second. Many computers have neither and NTP simply corrects the clock afterward as if it were off by one second. -- Darren

Robert Elz said:

Now notice the notable lack of any reference to any table of leap seconds in the calculations above. So, we have something that looks like TAI. Except the TAI time would be 14 (?) seconds different than this,

34

This is a bizarre definition of time from any physics, or astronomy sense,

Actually, it's not dissimilar to UT1. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On Jun 29, 2011, at 8:57 PM, Russ Allbery wrote:

Paul Koning <paul_koning@Dell.com> writes:

...

"Remove leap seconds from UTC" is clearly absurd, and I'm baffled that ACM would lend its good name to such a notion. UTC is defined as atomic time plus leap seconds, for good and sufficient reasons. And as was pointed out, TAI already exists for those who want atomic time plain, without leap seconds.

That isn't really what the ACM article says. Insofar as it makes an argument, it's arguing for just never declaring another leap second and letting UTC drift, possibly fixing that with a time zone change at the point at which enough error has accumulated to shift time by an hour. It isn't arguing for undoing any of the leap seconds that we've already been through.

Thanks. Interesting. That's certainly one way to "kick the can down the road".

The alternative proposal is that leap seconds be declared twenty years in advance ...

Is that actually possible? paul

Russ Allbery said:

...

...

The alternative proposal is that leap seconds be declared twenty years in advance ... Is that actually possible? Well, sure, provided that we're okay with twenty years of drift. It increases the divergence between UTC and the physical phenomenon that it's intended to mirror, of course, but it bounds that divergence at about thirty or forty years worth of divergence (assuming that we'll continue to use the current low rate of changes) instead of six to twelve months of divergence. Given the low rate of divergence currently, this doesn't seem like a big deal. Having noon be 20 seconds, or even a minute, off true value doesn't seem like it would be too horrible. Or at least the article in ACM was fairly convincing.

The first problem is that there's various things around which assume that the divergence will remain under a second. Nobody knows how many of them will break and how important that is. The second, longer-term problem is that the rate we need leap seconds is increasing quadratically. That makes keeping within that 1 second bound ever harder to predict. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

Guy Harris said:

What day is it right now? :-)

From what I can find, TAI is defined as "seconds since the TAI epoch", which, if this page

http://www.hko.gov.hk/gts/time/basicterms-TAI.htm

is correct, is "1958 January 1 d 0 h 0 min 0 s"; if so, presumably that's "1958 January 1 d 0 h 0 min 0 s GMT".

Not quite. TAI is a clock, with hours, minutes, and seconds. It was synchronised with GMT (UT1, actually) at the start of 1958.

I suspect that means that the answer to "what day is it right now" could differ between the UTC and TAI zones near the insertion of a leap second.

It differs anyway. At present TAI moves to a new day 34 seconds before UTC does.

Then again, it could differ between different locations on the earth....

TAI and UTC aren't time-zone dependent. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On Jun 29, 2011, at 11:27 PM, Robert Elz wrote:

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

There's "time" as a measure as the progress, of, well, *time*. "How many {fillintheblanko}seconds did this operation take"? Ultimately, that's the camp to which TAI belongs. And then there's "time" as in "what label do the dominant ape species on a ball of iron and rock with a layer of mud on top use to identify certain instants of time, based on the rotational and orbital properties of said ball?" Ultimately, that's the camp to which UTC belongs. The former is relatively simple, courtesy of cesium-133. The latter is more complicated, given that the orbit and rotational speed of the ball in question weren't set up with reference to the energy level difference between the two hyperfine levels of the ground state of the cesium-133 atom, and that both change over time. In the best of all possible worlds, time() would deal with the former, and localtime()/gmtime()/mktime() would deal with mapping the former to the latter.

...

The latter is more complicated, given that the orbit and rotational speed of the ball in question weren't set up with reference to the energy level difference between the two hyperfine levels of the ground state of the cesium-133 atom, and that both change over time.

*both*?  Surely, sir, you jest. 

I have a Cs atom calibrated by BIPM, preserved in a bottle of snake oil, which it breaks my heart to sell, but I have an old mother ... 

Both the orbit and the rotational speed, I think he might mean...

I'm going to tak a contrarian view -- at least from the perspective of the group here -- and assert that the Posix committee got it nearly right. (Or at least that the damage was done before the standardisation effort got under way.) Posix time, unfortunately, has served a dual purpose. It is used for measuring intervals - but it is also civil time: "what time is it on the clock on the wall?" And it has been used - from the very earliest days - as a calculation device for the civil clock. I would venture the guess that virtually all programs that depend on "seconds from 1 January 1970" actually are doing things like computing days between two times:" (time1/86400 - time2/86400). Programmers who do things ranging from financial applications to television schedules want this convenience. Eventually, those who do television schedules realize that they have to deal also with leap seconds and drop frames. But that sort of thing winds up being left to specialists: the people who code the business applications of television don't care about those details, don't want to care, and shouldn't have to care. Even the technical directors and videotape editors are usually ignorant of the details: "some seconds have only 29 frames. It's like leap year" is the usual level of understanding. And having an integer representation of civil time, that well-defined calendar algorithms can handle without auxiliary tables that need to be updated, is too great a convenience to pass up lightly. So: Make the TAI clock separate from the UTC clock. Synchronize the two, either using something like adjtimex() that makes the change almost imperceptible, or by making the change rare enough that it can be a planned-for event (the 'leap hour' proposal). I don't really care which. (The code that I've written does the first, because that's the best compromise available with today's standards.) But don't take away an integer "UTC clock" merely because it ticks irregularly. The irregular ticks are useful for the vast majority of people to whom leap seconds are an academic curiosity. Define a new set of APIs for dealing with TAI. If that's too much work, bite the bullet and accept leap hours. We won't need one in the lifetime of the prospective lifetime of the great-grandchildren of those in the cradle today. That may be kicking the can down the road, but it's a very long kick. -- 73 de ke9tv/2, Kevin

On 01/07/11 11:35, Guy Harris wrote:

On Jun 30, 2011, at 6:15 AM, Kevin Kenny wrote:

...

And it has been used - from the very earliest days - as a calculation device for the civil clock. I would venture the guess that virtually all programs that depend on "seconds from 1 January 1970" actually are doing things like computing days between two times:"

If you phrase that as "time intervals between two times", I might agree. If you restrict it to "days", I wouldn't; many of them calculate seconds.

...

(time1/86400 - time2/86400).

...a calculation that could report 0 days between two events happening on different days, if fewer than 86400 seconds elapse between them, and you're doing it as an integer division.

2011-06-29 22:00:00 (US Pacific time) is 1309410000; 2011-06-30 11:00:00 (US Pacific time) is 1309456800. 1309410000/86400 is 15155, as is 1309456800/86400.

But presumably it works fine for day boundaries in the UTC timezone with times in seconds since the POSIX epoch (ignoring leap seconds etc.). Presumably it works for other timezones if you add the appropriate offset(s) to time1 and time2 (the offsets added to time1 and time2 would be the same unless there have been DST or other changes in the meantime). -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-

Clive D.W. Feather <clive@davros.org> wrote:

Just to make things more complicated, civil time in the UK is GMT (approximately UT1) and *not* UTC. So clocks should never have 23:59:60.

De jure yes, but it is de facto UTC. GMT hasn't been maintained for decades and almost all the UK government-sponsored time signals provide UTC without DUT1. The UK government wishes to keep leap seconds. http://www.whatdotheyknow.com/request/uk_policy_on_leap_seconds Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Bailey: Southeast 5 to 7. Moderate or rough, occasionally slight in east at first. Rain. Moderate or good, occasionally poor.

On Jul 1, 2011, at 10:09 AM, Tony Finch wrote:

Clive D.W. Feather <clive@davros.org> wrote:

...

Just to make things more complicated, civil time in the UK is GMT (approximately UT1) and *not* UTC. So clocks should never have 23:59:60.

De jure yes, but it is de facto UTC. GMT hasn't been maintained for decades and almost all the UK government-sponsored time signals provide UTC without DUT1.

And apart from that, the UK keeps daylight savings, so in the summer civil time is an hour away from UTC. paul

Tony Finch said:

...

Just to make things more complicated, civil time in the UK is GMT (approximately UT1) and *not* UTC. So clocks should never have 23:59:60. De jure yes, but it is de facto UTC. GMT hasn't been maintained for decades and almost all the UK government-sponsored time signals provide UTC without DUT1.

MSF provides DUT1. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On Jul 1, 2011, at 5:45 AM, Clive D.W. Feather wrote:

Guy Harris said:

...

There *is* no "UTC clock" in POSIX. You cannot use only the POSIX APIs to convert a time_t, as returned by the POSIX time(), to the corresponding UTC time label, where the time label has HH:MM:SS; gmtime() will not do that for you, because gmtime() thinks that every minute ("minute" in the sense of period of time in which the minute counter of a clock ticks over) has exactly 60 seconds, which, for UTC time's minute counter, is not true.

Not quite. The conversion is well-defined,

...in the sense that "we have a formula that takes a time_t and spits out year/month/day/hour/minute/second".

but sometimes two values on one side map to one value on the other side.

...so that there's no way to get the right UTC label for 2008-12-31 23:59:60 out of POSIX. I.e., you cannot use only the POSIX APIs to convert a time_t, as returned by the POSIX time(), to the corresponding UTC time label for all values of time_t.

On Jul 1, 2011, at 13:12, Tim Parenti wrote:

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.

(OP here.) The vote on "Proposal TF-460-7" is coming up in January 2012 (for possible retirement in 2018), so it'd be prudent to wait until then. But if the proponents of abolishing it do have a need, then having a TZ=TAI value would be a good option in helping them. As PHK's ACM article mentions:

If the proposal fails to gain 70 percent of the votes, then leap seconds will continue, and we had better start fixing computers to deal properly, or at least more predictably, with them.

http://queue.acm.org/detail.cfm?id=1967009 POSIX in particular may may to clarify what to do in the situations mentioned in this thread.

On Jun 30, 2011, at 4:58 AM, Andy Lipscomb wrote:

Both the orbit and the rotational speed, I think he might mean...

Precisely.

On Thu, Jun 30, 2011 at 7:24 AM, David Magda <dmagda@ee.ryerson.ca> wrote:

Unix-y systems keep time in POSIX "time scale" (?), and NTP uses UTC.

Given that TAI is neither of these, if one would like to use a time scale that does not experience leap seconds, one need a way of telling the various time routines to translate the internal POSIX/UTC counters to a different "local" time.

As I type this, my TZ=America/Toronto, and so the time is roughly:

       Thu Jun 30 07:20:50 EDT 2011        Thu Jun 30 11:20:50 UTC 2011

but if I set TZ=TAI, it would convert my NTP synced computer clock up by 34s:

       Thu Jun 30 11:21:24 TAI 2011

So yes, TAI is "just a count of seconds from its offset", but how does one tell a utility like date(1) to add those seconds? Hence my original question: if all these people who can't / don't want to deal with leap seconds want something that ignores it, what option would they have? Would a TZ=TAI be possible?

Use the "right" files, and judiciously place a call to the ado localtime.c:time2posix() in your NTP server. Then all is well. [You may need a time2posix() in other places that assume 60-second minutes, but when I did just that circa 1990 there were but a few.]

On 6/30/2011 2:27 AM, Robert Elz wrote:

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

I've never heard this before. Everywhere i've seen it described it's "34 seconds ahead of UTC" - and UTC has all those. which implies at 00:29:11 UTC it's 00:29:45 TAI [of the same day, except of course for those 34 seconds between the two times' 00:00:00]

Robert Elz said:

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.

Sorry, that's not so.

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.

I'm afraid that's wrong. TAI *does* have a concept of years, months, days, hours, and minutes. It makes perfect sense to say TZ=TAI and you'll get a meaningful answer (which is currently 34 seconds ahead of TZ=UTC). -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646