Re: [LEAPSECS] Leap second relationship to ISO 8601
Poul-Henning Kamp wrote: > >> > > For example, a date and time in New York City might be represented > >> > > as 2014-07-04T00:00:00-05:00 [...] > >> > > >> > The former is incorrect. > >> > >> Incorrect where? > > > >The UTC offset in New York at that time was not -05:00 so that cannot be a > >time in New York. > > You're missing the quiet genius of 8601 here: > > Who said the date and time of the event which happened in New York > were represented on local timescale there at the time ? I thought that is what Brooks was trying to do. Obviously when ISO 8601 talks about local time it is leaving it to some unspecified context to determine what locality the time belongs to; in this discussion the locality is New York, and it would be particularly contrary of Brooks to want to represent the time in New York using some other place's local time. > By explicitly stating the UTC offset numerically, 8601 decouples > it from any cultural basis it might have had and becomes a standalone > representation of a moment in time. Right, and this is good for many purposes, e.g. recording times of events now or in the past. However for events in the future (meetings etc.) you need to record a time and a place, because the UTC offset and time zone rules are not predictable. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second relationship to ISO 8601
Tony Finch wrote > Right, and this is good for many purposes, e.g. recording times of events now or in the past. However for events in the future (meetings etc.) you need to record a time and a place, because the UTC offset and time zone rules are not predictable. Even better, local time can be used to specify recurring meetings which begin at the same local time, but different UTC times, because of daylight saving time. ISO 8601 has a notation for recurring events, although I have not mastered it. Gerry Ashton ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second relationship to ISO 8601
Tony Finch said: > However for events in the future (meetings etc.) you > need to record a time and a place, because the UTC offset and time zone > rules are not predictable. More precisely, the accuracy of predictions varies. (I'd have a lot of confidence in the 2005 offsets for England. Rather less for those in Palestine.) -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second relationship to ISO 8601
In message , Tony F inch writes: >However for events in the future (meetings etc.) you >need to record a time and a place, because the UTC offset and time zone >rules are not predictable. The main problem here is to get people to give you enough information in the first place. For instance: I add a meeting to my calendar at 10:00 day after tomorrow. Tomorrow I fly to Ulan Batoor. When is the meeting ? It could be a meeting in Ulan Batoor, it could be a phone-meeting back in Denmark or it could be a teleconference with Melbourne. Many heuristic attempts have been made to "DWIM" and all fails. 8601 is not even attempting to get anywhere near that problem, all it tries to do, is ensure that when I write a timestamp with some number of components, you will read it the same way and get the same components with the same numerical values. But 8601 doesn't care or try to make sense of what the numbers might mean. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second relationship to ISO 8601
On 2014-08-28 08:10 AM, Poul-Henning Kamp wrote: In message , Tony F inch writes: However for events in the future (meetings etc.) you need to record a time and a place, because the UTC offset and time zone rules are not predictable. The main problem here is to get people to give you enough information in the first place. For instance: I add a meeting to my calendar at 10:00 day after tomorrow. Tomorrow I fly to Ulan Batoor. When is the meeting ? It could be a meeting in Ulan Batoor, it could be a phone-meeting back in Denmark or it could be a teleconference with Melbourne. Many heuristic attempts have been made to "DWIM" and all fails. 8601 is not even attempting to get anywhere near that problem, all it tries to do, is ensure that when I write a timestamp with some number of components, you will read it the same way and get the same components with the same numerical values. But 8601 doesn't care or try to make sense of what the numbers might mean. An organization I work with has been using a web-based meeting scheduling calendar that gives meeting date-time notifications. Recently it has been announcing meetings as, for example - "When: Wednesday, September 24, 2014 11:00 AM-12:30 PM. (UTC-05:00) Eastern Time (US & Canada)" Of course Daylight is in effect on the east coast, so its completely wrong. What is intended is 2014-09-24T12:00-04:00 (noon, "Eastern Daylight Time"). Ironic that a web site serving a working group concerned with timekeeping gets this go badly confused. It would better if 8601 provided a DST flag, so you might have something like 2014-09-24T12:00-05:00S1, where "-05:00" is the fixed offset from UTC for the locality, and "S1" means "(Daylight) *S*avings in effect". -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second relationship to ISO 8601
Brooks Harris said: > An organization I work with has been using a web-based meeting > scheduling calendar that gives meeting date-time notifications. > > Recently it has been announcing meetings as, for example - > > "When: Wednesday, September 24, 2014 11:00 AM-12:30 PM. (UTC-05:00) > Eastern Time (US & Canada)" > > Of course Daylight is in effect on the east coast, so its completely > wrong. What is intended is 2014-09-24T12:00-04:00 (noon, "Eastern > Daylight Time"). Microsoft's calendaring stuff does that. I keep getting stuff that says it's at (say) 10:00 UTC, plus "the UTC offset doesn't take account of daylight savings time", when what it means is 10:00 BST. Even worse is the ones that say 10:00 UTC+01:00, which actually mean 09:00 BST. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second relationship to ISO 8601
Brooks Harris wrote: > > > > Most explainations, and the spec itself, say that NTP does not account > > > for Leap Seconds, and it does not, *explicitly*. Note, however, that > > > 2272060800 secs / 86400 = 26297 days *exactly*. There were 10 Leap > > > Seconds in effect at 1972-01-01T00:00:00Z (UTC), so there must be 10 > > > Leap Seconds in effect at the NTP "prime epoch of era zero", "0 h 1 > > > January 1900 UTC". > > That reasoning is faulty. > I hope not :-\ > > > Figure 4 of RFC 5905 also says that the > > NTP timestamp for 1999-12-31 is 3155587200, and > > (3155587200-2272060800)/86400 is 10226 days exactly. > 1999-12-31 is after 1972, and 32 Leap Seconds are in effect - 10 initial at > 1972 plus 22 decreed inserts. OK, so apply that same reasoning to dates before 1972, when UTC had subsecond leaps and rate changes. Why not say that during this period the NTP timescale (had it existed) would also have had subsecond leaps and rate changes, communicated separately from the timestamps like leapseconds are now? A fixed 10s offset is obviously wrong because there is a fixed offset between POSIX and NTP timestamps (except during leap seconds), so there is a POSIX-like fixed mapping from wall clock time to NTP timestamps. (By "wall clock time" I mean UT of whichever variety was in use at that time.) So at the point in time where TAI was established, when it coincided with UT, the NTP leap second count has to be 0. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second relationship to ISO 8601
Brooks Harris said: > In particular, 8601 implies use of "offset > from UTC", as indication of "local time", but conflates this with > Daylight Savings. No, it doesn't. It uses offset from UTC as an indication of, wait for it, offset from UTC. > For example, a date and time in New York City might be > represented as 2014-07-04T00:00:00-05:00 which misses the fact that > Daylight was in effect, or 2014-07-04T00:00:00-04:00 which misses the > fact the the fixed timezone offset is -05:00. No. 2014-07-04T00:00:00-05:00 means the start of the day according to a clock observing an offset of -5 hours. Someone in New York City might have such a clock if they needed to correspond with Chicago. 2014-07-04T00:00:00-04:00 means the start of the day according to a clock observing an offset of -5 hours. That is the offset typically observed [1] in New York City on that date. The use of an offset does *NOT* imply either a time zone or the presence or absence of an bi-annual shift. My office in Cambridge has clocks on the wall showing the time in offsets -07:00, -04:00, +01:00, +02:00, +05:30, and +08:00, because those are the ones we regularly communicate. Though they all show different numbers, they are all showing the same time. [1] But see R.v Haddock [1967] BBC 1.4. -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second relationship to ISO 8601
Poul-Henning Kamp wrote: > > >However for events in the future (meetings etc.) you need to record a > >time and a place, because the UTC offset and time zone rules are not > >predictable. > > The main problem here is to get people to give you enough information > in the first place. > > For instance: > > I add a meeting to my calendar at 10:00 day after tomorrow. > > Tomorrow I fly to Ulan Batoor. > > When is the meeting ? > > It could be a meeting in Ulan Batoor, it could be a phone-meeting > back in Denmark or it could be a teleconference with Melbourne. > > Many heuristic attempts have been made to "DWIM" and all fails. The meeting organizer has to specify a (single) place. In many cases (like teleconferences) you will want to add secondary locations to the details of the meeting. These locations don't affect the time of the meeting (if timezone changes occur) but they are useful for displaying the local times of the meeting for the remote participants, and useful for the organizer to see if the proposed time is reasonable for eveyone who needs to participate. And if timezone changes occur it's easy to find the meetings which might be affected, i.e. the ones with multiple locations not all of which are affected by the change, which is exactly the ones that require human attention. (Compare that last situation with Microsoft Exchange, which fixes the UTC offset of a meeting at the time it is organized - or at least it did in 2007 when the North American DST rules changed. Exchange admins had to run a special tool to adjust the times of all future meetings in North America.) Another interesting case is a meeting on a plane where the choice of location is not clear. But if you specify "departing from X" or "arriving at Y" it becomes clear which time zone to use and when you are planning to adjust your clocks from X time to Y time. No need for DWIM guessing games. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap second relationship to ISO 8601
Brooks Harris said: >> ISO 8601 does not represent daylight saving nor time zones. > It can represent both, but incompletely, or ambiguously. The "time > element" called "zone designator" conflates "offset from UTC" and > "Daylight Savings offset" in the "time element" called "zone designator". No. Its "zone designator" is actually offset from UTC. This is because it is using a different meaning for the term "zone" than the TZ list does. Compare the "military time zones". Without physically moving, for part of the year I am in "zone" Zulu and for part of the year I am in "zone" Alpha. That's their definition of "time zone". The TZ list would say that, at all times, I am in "zone" Europe/London. > Incorrect where? 2014-07-04T00:00:00-05:00 would have been correct in > Chicago. We only know this because we know a-priori Daylight Savings was > in effect in that jurisdiction. No. Because we know that Chicago was using offset UTC-5 at the time. > It was 2014-07-04T00:00:00-06:00 > "Mountain Daylight Time" while it was 2014-07-04T00:00:00-07:00 in > Arizona, which does not observe Daylight Savings. But note that these are *DIFFERENT* times. That one happened an hour after the other one. > Strictly from the 8601 representation we don't know if Daylight was in > effect or even if it is observed in the jurisdiction, so we can't > distinguish the "fixed offset from UTC to the local jurisdiction". I've just looked at ISO 8601:2004 and can't find this phrase at all. What I *do* find is: 2.1.14 standard time time scale derived from coordinated universal time, UTC, by a time shift established in a given location by the competent authority [IEC 60050-111] NOTE This time shift may be varied in the course of a year. It is made clear in 4.2.5.1 and 4.2.5.2 that the offset notation shows "the difference between the time scale of local time and UTC", and nothing else. It is also noted in 4.2.2.1 that "no provisions have been made to prevent ambiguities in expressions that result from discontinuities in the time scale of local time (e.g. daylight saving time).". -- Clive D.W. Feather | If you lie to the compiler, Email: cl...@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
