Two things: Can a transition time ever reasonably fall _on_ a leap second, and can the zic input format represent this case? I am sketching out a design for a new time zone file format, and it occurs to me that it might be a good idea to specify transitions with POSIX timestamps so the data regarding one time zone is independent of whether leap seconds are enabled or not.
random832@fastmail.us said:
Two things: Can a transition time ever reasonably fall _on_ a leap second, and can the zic input format represent this case?
It's very unlikely, but theoretically possible. -- 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 2013-09-11 16:51, Clive D.W. Feather wrote:
random832@fastmail.us said:
Two things: Can a transition time ever reasonably fall _on_ a leap second, and can the zic input format represent this case?
It's very unlikely, but theoretically possible.
A leap second would be inserted at 23:59:60 UTC, so I'm not sure it's possible to have a DST transition at the start of a leap second, but you could get a DST transition at the end of a leap second. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On Wed, Sep 11, 2013, at 11:58, Ian Abbott wrote:
A leap second would be inserted at 23:59:60 UTC, so I'm not sure it's possible to have a DST transition at the start of a leap second, but you could get a DST transition at the end of a leap second.
Otherwise known as the start of the next second after, and i'm pretty sure transitions are defined in the file by the second that starts at the time of the transition.
In practice the leap seconds tend to be inserted at times of the year that aren't typical DST change season (end of june or end of december) http://en.wikipedia.org/wiki/Leap_second#Insertion_of_leap_seconds So odds are that in practice it's not a problem. It could be if a jurisdiction decide to change it's timezone at the beginning of the year though. On 11/09/2013 11:58 AM, Ian Abbott wrote:
On 2013-09-11 16:51, Clive D.W. Feather wrote:
random832@fastmail.us said:
Two things: Can a transition time ever reasonably fall _on_ a leap second, and can the zic input format represent this case?
It's very unlikely, but theoretically possible.
A leap second would be inserted at 23:59:60 UTC, so I'm not sure it's possible to have a DST transition at the start of a leap second, but you could get a DST transition at the end of a leap second.
-- Oracle Email Signature Logo Patrice Scattolin | Principal Member Technical Staff | 514.905.8744 Oracle WebCenter Mobile applications 600 Blvd de Maisonneuve West Suite 1900 Montreal, Quebec
random832@fastmail.us wrote:
Two things: Can a transition time ever reasonably fall _on_ a leap second,
Reasonably, no. Where the underlying base time scale has leap seconds, timezones to be used with that time scale can only use offsets of integral minutes. In that context it would be most strange to use a transition time that was not on a minute boundary. Every timezone used in practice has been that way since Liberia switched from LMT in 1972. It's theoretically possible to have a non-minute transition, of course, but transitioning on a leap second would further require that the authority defining the timezone specifically intends it to be used with leap seconds (unusual), and specifically intends to be awkward.
and can the zic input format represent this case?
Textually the leap second can be represented uniquely as ...:60, and from inspection of the source I believe zic will actually accept it, but it doesn't preserve the distinction between that and the following second.
POSIX timestamps so the data regarding one time zone is independent of whether leap seconds are enabled or not.
Generalising a bit: it is sensible to represent a timezone's behaviour in a way that's independent of the local interpretation of time_t. Decoding time_t to a UTC time should be a separate step from converting a UTC time to local time. -zefram
On Wed 2013-09-11T16:55:49 +0100, Zefram hath writ:
Generalising a bit: it is sensible to represent a timezone's behaviour in a way that's independent of the local interpretation of time_t. Decoding time_t to a UTC time should be a separate step from converting a UTC time to local time.
Adding to that, the term UTC is polysemic in the context of computer timekeeping. I urge anyone using the term UTC to be explicit about whether the intended meaning is UTC[ITU-R] (has leap seconds) or UTC[POSIX] (no leap seconds). This may help avoid misunderstandings. -- 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 Wed, Sep 11, 2013, at 12:18, Steve Allen wrote:
Adding to that, the term UTC is polysemic in the context of computer timekeeping. I urge anyone using the term UTC to be explicit about whether the intended meaning is UTC[ITU-R] (has leap seconds) or UTC[POSIX] (no leap seconds). This may help avoid misunderstandings.
There is no such thing as UTC[POSIX] as you define it. POSIX timestamps are an incomplete mapping of integers to UTC[ITU-R]. There also exists the theoretical possibility of an integer that represents an invalid UTC[ITU-R] timestamp ending in 23:59:59 where UTC[ITU-R] itself advances from 23:59:58 to 00:00:00, but it remains theoretical as there have been no actual negative leap seconds. To say that "UTC[POSIX]" has "no leap seconds" is to imply it has ever in fact differed from UTC[ITU-R] by more than one second. If such a thing as "UTC[POSIX]" exists at all, it merely labels leap seconds differently, in the same way that a timezone with daylight saving may label two different moments as "02:30:00". The fact that POSIX difftime() may return a value somewhat smaller than the actual number of seconds that passed between the two timestamps passed to it does not change this.
The practical point is that POSIX time can't represent leap seconds, and that systems in practice get around this problems in various ways, none of them standardized yet. There is an effort underway to standardize this for RTP. The draft says the POSIX clock jumps back at the start of an inserted leap second; see Gross K, van Brandeburg R. RTP and Leap Seconds (2013-08-27) http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-04 But (as they mention) this definition doesn't match how well-regulated POSIX clocks keep time in practice. There was an earlier proposal to standardize this: Kuhn M. Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS) (2006-01) http://tools.ietf.org/html/draft-kuhn-leapsecond-00 but as far as I know, it has not been adopted in practice.
On Wed 2013-09-11T10:07:27 -0700, Paul Eggert hath writ:
But (as they mention) this definition doesn't match how well-regulated POSIX clocks keep time in practice. There was an earlier proposal to standardize this:
Kuhn M. Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS) (2006-01) http://tools.ietf.org/html/draft-kuhn-leapsecond-00
but as far as I know, it has not been adopted in practice.
This is effectively the same as Google's "Leap Smear". (And the smear is an indication that even with the resources of Google, defining and implementing their own corporate worldwide time scale was more feasible than addressing the issues of leap seconds in a heterogeneous ensemble of systems.) -- 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
I believe in the astronomy world there is a motion in front of the IAU to drop leap seconds altogether and let UTC drift apart from UT1 On 2013-09-11 13:07, Paul Eggert wrote:
The practical point is that POSIX time can't represent leap seconds, and that systems in practice get around this problems in various ways, none of them standardized yet.
There is an effort underway to standardize this for RTP. The draft says the POSIX clock jumps back at the start of an inserted leap second; see
Gross K, van Brandeburg R. RTP and Leap Seconds (2013-08-27) http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-04
But (as they mention) this definition doesn't match how well-regulated POSIX clocks keep time in practice. There was an earlier proposal to standardize this:
Kuhn M. Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS) (2006-01) http://tools.ietf.org/html/draft-kuhn-leapsecond-00
but as far as I know, it has not been adopted in practice.
--
David Patte ??? said:
I believe in the astronomy world there is a motion in front of the IAU to drop leap seconds altogether and let UTC drift apart from UT1
Actually, it's the astronomers who want to keep leap seconds; just about everyone else wants rid of them. But please can we reserve this debate to the leap seconds mailing list; I really don't want to read it twice. -- 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
That's my recollection also with some countries more adamant about it than others. From memory, the decision was contentious and was postponed to later (2016?) The leap second acts like a leap year in correcting the drifts in our time measurements. On 11/09/2013 10:29 PM, Clive D.W. Feather wrote:
David Patte ??? said:
I believe in the astronomy world there is a motion in front of the IAU to drop leap seconds altogether and let UTC drift apart from UT1 Actually, it's the astronomers who want to keep leap seconds; just about everyone else wants rid of them.
But please can we reserve this debate to the leap seconds mailing list; I really don't want to read it twice.
-- Oracle Email Signature Logo Patrice Scattolin | Principal Member Technical Staff | 514.905.8744 Oracle WebCenter Mobile applications 600 Blvd de Maisonneuve West Suite 1900 Montreal, Quebec
On 11 September 2013 18:07, Paul Eggert <eggert@cs.ucla.edu> wrote:
There was an earlier proposal to standardize this:
Kuhn M. Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS) (2006-01) http://tools.ietf.org/html/draft-kuhn-leapsecond-00
but as far as I know, it has not been adopted in practice.
JSR-310 is going to use it: http://download.java.net/jdk8/docs/api/java/time/Instant.html Stephen
Zefram wrote:
transitioning on a leap second would further require that the authority defining the timezone specifically intends it to be used with leap seconds
No, typically transitions are legally specified in terms of local time before the transition. I suppose it's theoretically possible that an authority currently using some sort of mean time could say "we change at 02:00 local time", and this is the start of, or in the middle of, a leap second. Not that the mapping between leap seconds and things like BMT are well-defined -- how does one insert a leap second at (say) 01:59:59.9 local time? I wouldn't worry about this much, as it's never happened in the past and is unlikely to occur in the future.
it is sensible to represent a timezone's behaviour in a way that's independent of the local interpretation of time_t. Decoding time_t to a UTC time should be a separate step from converting a UTC time to local time.
Ah, so the local authority says "we change our time zone at 02:30 local time", but due to a daylight-saving transition there are two instants of time labeled 02:30 local time, and the law states somewhere else which of the two instants they mean, but the tz format gives no way to specify which local time is meant. This would set a new record for legal cluelessness about time. It isn't going to happen, but the current zic input format could model it with the "s" or "u" suffix, I suppose.
On Wed, Sep 11, 2013, at 12:36, Paul Eggert wrote:
No, typically transitions are legally specified in terms of local time before the transition.
I meant the actual TIME specified is the second of the transition (ending :00 typically), not the second before (ending :59 typically), even when that means that, being specified in terms of local time before the transition, it names a second in which civil time is not actually kept with the offset that was used before the transition. We say 2:00, not 1:59:59.
I suppose it's theoretically possible that an authority currently using some sort of mean time could say "we change at 02:00 local time", and this is the start of, or in the middle of, a leap second. Not that the mapping between leap seconds and things like BMT are well-defined
Funny, I'd just reached the point of asking about this - my current description of the data type of tt_gmtoff reads as follows: OFFSET: A four-byte value representing an offset from UTC. When the value is evenly divisible by 60, N/60 represents the number of minutes. When the value is not evenly divisible by 60, the behavior in the vicinity of leap seconds is unspecified, otherwise N represents the number of seconds. I don't have anything better to put there than "unspecified". I suspect the most reasonable behavior would be to insert the second at the end of the minute that contains the UTC leap second, e.g. 28 29 30 31 32 .. 58 59 60 00 01 02 03 .. 28 29 30 31 32 --- UTC 58 59 00 01 02 .. 28 29 30 31 32 33 34 .. 59 60 00 01 02 --- UTC+00:00:30 30 30 30 30 30 .. 30 30 30 31 31 31 31 .. 31 31 30 30 30 --- difference. I don't know how easy it is to make a closed-form algorithm for this case, though. Anyone know what the actual behavior of localtime is in the current code in situations like this? I suspect the leap second code is terribly under-tested.
Paul Eggert wrote:
No, typically transitions are legally specified in terms of local time before the transition.
Indeed, but that doesn't affect my argument.
I suppose it's theoretically possible that an authority currently using some sort of mean time
There is no such timezone currently, and hasn't been since 1972. If there were, you still run into the issue that LMT amounts to UT1+offset, not UTC+offset, and the tz database doesn't distinguish between UT1 and UTC. (Strict meaning of UTC here, as usual for me.) The apparent need to transition at onset of a leap second would depend on the sub-second difference between UT1 and UTC that the database doesn't model. Really, you'd only have a problem here if you're simultaneously applying the loose interpretation of UTC ~= UT1 and the strict interpretation of UTC with leap seconds. Unfortunately this is a common combination in computer timekeeping. (Also, obliquely, subject of the philosophical opening section of my paper to which I pointed yesterday.)
how does one insert a leap second at (say) 01:59:59.9 local time?
Quite. That's the basis of my statement that timezones to be used with leap seconds can only use offsets of whole minutes. (A leap second occurs everywhere simultaneously, regardless of timezone; zic's concept of a "rolling leap second" is bogus.)
Ah, so the local authority says "we change our time zone at 02:30 local time", but due to a daylight-saving transition there are two instants of time labeled 02:30 local time,
That kind of ambiguity is nothing to do with the leap second issues being discussed in this thread. -zefram
On 09/11/13 10:18, Zefram wrote:
Really, you'd only have a problem here if you're simultaneously applying the loose interpretation of UTC ~= UT1 and the strict interpretation of UTC with leap seconds.
Yes, you're right -- sorry for the confusion. We're lucky that Liberia ended the last use of not-a-multiple-of-a-minute UT offset in May 1972, the month before the first leap second hit the clocks.
participants (9)
-
Clive D.W. Feather -
David Patte ₯ -
Ian Abbott -
Patrice Scattolin -
Paul Eggert -
random832＠fastmail.us -
Stephen Colebourne -
Steve Allen -
Zefram