From ashtongj at comcast.net Mon Feb 9 11:49:11 2009 From: ashtongj at comcast.net (Gerard Ashton) Date: Mon, 9 Feb 2009 11:49:11 -0500 Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? Message-ID: <09364CFCA84C4DBE82562A5A33318D50@grendel> Given that UTC did not exist in its present form (and as described in ISO 8601:2004, that is, with leap seconds) until 1 January 1972, and given that the ISO 8601:2004 standard states "[Z] is used as UTC designator." (p. 12) is it fair to conclude that it is improper to use the "Z" designator for any date/time in the ISO 8601 format prior to 1 January 1972? If indeed that is improper, would it not be incumbent on anyone who wishes to express a UT time/date in a format that looks like ISO 8601 format to either (1) leave off the designator, and communicate the fact that the it is UT through some other means, or, (2) establish their own standard that expressly modifies ISO 8601 to indicate that "Z" is the UTC designator after 1 January 1972, and the UT designatior before then? Gerry Ashton From zefram at fysh.org Mon Feb 9 12:00:01 2009 From: zefram at fysh.org (Zefram) Date: Mon, 9 Feb 2009 17:00:01 +0000 Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? In-Reply-To: <09364CFCA84C4DBE82562A5A33318D50@grendel> References: <09364CFCA84C4DBE82562A5A33318D50@grendel> Message-ID: <20090209170001.GA16377@fysh.org> Gerard Ashton wrote: >is it fair to conclude that it is improper to use the "Z" designator for any >date/time in the ISO 8601 format prior to 1 January 1972? That's a tricky area. We discussed the interpretation of "Z" a little in 2008-12, in a thread titled "Footnote about CCITT and UTC". I commented: :Section 4.2.5 ("Local time and Coordinated Universal Time (UTC)") :is about representing the difference between local time and UTC. :It doesn't actually use the term "standard time", but clearly for the :difference to be exact the local time must be a standard time as defined :in section 2.1.4. : :The other representation that is defined specifically by reference to :UTC is in section 4.2.4 ("UTC of day"). This is about the use of "Z" :to tag a time-of-day as being on the UTC time scale. : :So, if we follow the standard as written, I can validly (in ISO :8601) state that the BST (British Summer Time, = GMT + 1h) time is :"22:32:12.123", but I can't write it as "22:32:12.123+01:00" or describe :BST as "+01:00". The offset from UTC to BST is not exactly one hour, :but some constantly-changing value that is best determined by the IERS. :Likewise, I can write the GMT time, which is the legal time in Britain, :as "21:32:12.123", but not as "21:32:12.123Z", because GMT is not :precisely UTC. (I'm using "GMT" in the strict sense here, of course.) : :Unfortunately ISO 8601 does not supply any way to designate UT1 or any :other flavour of UT except UTC. Thus, strictly speaking, there is no :way to designate any local time that is based on UT1 rather than UTC. :As we know from previous discussions on this list, there are quite a few :such time scales with current legislative endorsement. (And a few that :can't decide which they're based on.) : :It seems to me that the standard would be rather more useful if "standard :time" were defined more according to its original meaning: a local time :scale defined by an offset from UT, rather than specifically from UTC. :The timezone designation material should correspondingly refer to UT :rather than UTC, and the "Z" should probably follow by designating UT. :All of these would be explicitly vague as to which flavour of UT is :being referred to. -zefram From phk at phk.freebsd.dk Mon Feb 9 12:58:04 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 09 Feb 2009 17:58:04 +0000 Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? In-Reply-To: Your message of "Mon, 09 Feb 2009 11:49:11 EST." <09364CFCA84C4DBE82562A5A33318D50@grendel> Message-ID: <39752.1234202284@critter.freebsd.dk> In message <09364CFCA84C4DBE82562A5A33318D50 at grendel>, "Gerard Ashton" writes: >is it fair to conclude that it is improper to use the "Z" designator for any >date/time in the ISO 8601 format prior to 1 January 1972? No. "Zulu Time" is much older than 1972 and the 'Z' designator goes waaay back. I can't remember if the letter designators of the timezones were decided on the merdidian conference (188x, Washington) or if they were just discussed, but that is the sort of age. International telegrams used the letter designators in some cases. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From imp at bsdimp.com Mon Feb 9 13:26:10 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Mon, 09 Feb 2009 11:26:10 -0700 (MST) Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? In-Reply-To: <09364CFCA84C4DBE82562A5A33318D50@grendel> References: <09364CFCA84C4DBE82562A5A33318D50@grendel> Message-ID: <20090209.112610.-100612842.imp@bsdimp.com> In message: <09364CFCA84C4DBE82562A5A33318D50 at grendel> "Gerard Ashton" writes: : Given that UTC did not exist in its present form (and as described : in ISO 8601:2004, that is, with leap seconds) until 1 January 1972, : : and : : given that the ISO 8601:2004 standard states "[Z] is used as UTC : designator." : (p. 12) : : is it fair to conclude that it is improper to use the "Z" designator for any : date/time in the ISO 8601 format prior to 1 January 1972? Why would it be improper? UTC has existed as a continuous[*] time scale since 1958, although the name is much newer than that. Just because the leap second rules were different prior to 1972 doesn't mean that UTC didn't exist prior to that. Just that the rules were different. : If indeed that is improper, would it not be incumbent on anyone who wishes : to express a UT time/date in a format that looks like ISO 8601 format to : either : : (1) leave off the designator, and communicate the fact that the it is UT : through : some other means, or, : : (2) establish their own standard that expressly modifies ISO 8601 to : indicate : that "Z" is the UTC designator after 1 January 1972, and the UT designatior : before : then? Usually people just assume that times before 1972 just don't have leap seconds, but are otherwise UTC. The adjustments to UTC prior to 1972 were such that they can be viewed as continuous and the details can be safely ignored for all but the most demanding timing applications dealing with historical data. Of course, you'd have to ask the ISO 8601:2004 authors if it is improper or not. Warner [*] continuous means here uninterrupted, as opposed to the usual arguments that come up at leap second over whether they are discontinuities or just an irregular radix. : Gerry Ashton : : _______________________________________________ : LEAPSECS mailing list : LEAPSECS at leapsecond.com : http://six.pairlist.net/mailman/listinfo/leapsecs : : From ashtongj at comcast.net Mon Feb 9 13:43:35 2009 From: ashtongj at comcast.net (Gerard Ashton) Date: Mon, 9 Feb 2009 13:43:35 -0500 Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? In-Reply-To: <39752.1234202284@critter.freebsd.dk> Message-ID: <625029C6E1F142B688CEBEDECDFAD8C9@grendel> I asked "is it fair to conclude that it is improper to use the 'Z' designator for any date/time in the ISO 8601 format prior to 1 January 1972?" Poul-Henning Kamp replied "No. 'Zulu Time' is much older than 1972 and the 'Z' designator goes waaay back." I must disagree with that reasoning. The meaning of a word with a long-standing meaning may be redefined within a particular document. For example, a law might specify that within that particular act, the word "state" includes Puerto Rico, even though that defies the ordinary meaning of "state". Similarly, within ISO 8601, "Z" designates "UTC" and any meaning it may have had for most of the 20th century outside that standard is irrelevant. Gerry Ashton From phk at phk.freebsd.dk Mon Feb 9 13:57:07 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 09 Feb 2009 18:57:07 +0000 Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? In-Reply-To: Your message of "Mon, 09 Feb 2009 13:43:35 EST." <625029C6E1F142B688CEBEDECDFAD8C9@grendel> Message-ID: <40037.1234205827@critter.freebsd.dk> In message <625029C6E1F142B688CEBEDECDFAD8C9 at grendel>, "Gerard Ashton" writes: >Similarly, within ISO 8601, "Z" designates "UTC" and any meaning it may >have had for most of the 20th century outside that standard is irrelevant. The meaning 'Z' had before ISO8601, and which ISO8601 codified, was "UTC". If you look at the Canadian time-station CHU's QSL card: http://flickr.com/photos/bneely/223853969/ You will notice that the timezones have letters on the illustration on the wall. It is not clear to me if the zero meridian have 'N' or 'Z' as designator. The painting is supposed to despict a meeting in 1879 where Sandford Flemming first laid out his idea for timezones. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From lang at unb.ca Mon Feb 9 14:13:11 2009 From: lang at unb.ca (Richard B. Langley) Date: Mon, 9 Feb 2009 15:13:11 -0400 Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? In-Reply-To: <40037.1234205827@critter.freebsd.dk> References: <40037.1234205827@critter.freebsd.dk> Message-ID: <1234206791.4990804737c5d@webmail.unb.ca> Quoting Poul-Henning Kamp : > In message <625029C6E1F142B688CEBEDECDFAD8C9 at grendel>, "Gerard Ashton" writes: > > >Similarly, within ISO 8601, "Z" designates "UTC" and any meaning it may > >have had for most of the 20th century outside that standard is irrelevant. > > The meaning 'Z' had before ISO8601, and which ISO8601 codified, was "UTC". > > If you look at the Canadian time-station CHU's QSL card: > > http://flickr.com/photos/bneely/223853969/ > > You will notice that the timezones have letters on the illustration > on the wall. It is not clear to me if the zero meridian have 'N' or > 'Z' as designator. Neither. It is "M." I have a scan of a B&W photo of the painting if anyone is interested. -- Richard Langley > The painting is supposed to despict a meeting in 1879 where Sandford > Flemming first laid out his idea for timezones. > > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at 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 at leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs > =============================================================================== Richard B. Langley E-mail: lang at unb.ca Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ Dept. of Geodesy and Geomatics Engineering Phone: +1 506 453-5142 University of New Brunswick Fax: +1 506 453-4943 Fredericton, N.B., Canada E3B 5A3 Fredericton? Where's that? See: http://www.city.fredericton.nb.ca/ =============================================================================== From seaman at noao.edu Mon Feb 9 14:37:57 2009 From: seaman at noao.edu (Rob Seaman) Date: Mon, 9 Feb 2009 12:37:57 -0700 Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? In-Reply-To: <39752.1234202284@critter.freebsd.dk> References: <39752.1234202284@critter.freebsd.dk> Message-ID: Hi, There are requirements here (unstated as usual :-) from both historical and future usage. It is important to tie them together properly. This is particularly true if entertaining the possibility of sundering UTC from UT. Poul-Henning Kamp wrote: > "Zulu Time" is much older than 1972 and the 'Z' designator goes > waaay back. From this point of view, Z means simply "Universal Time". That is, there was an adoption by ISO 8601 of a prior meaning. ITU must clarify such contingent issues if UTC is to be amputated from the broader meaning of Universal Time. (Or ITU might want to invest some brain cells in considering what it will do regarding the mess it will leave behind :-) Gerard Ashton wrote: > Similarly, within ISO 8601, "Z" designates "UTC" and any meaning it > may have had for most of the 20th century outside that standard is > irrelevant. I don't know if I agree with the latter part of the sentence since Z retains usage outside of ISO 8601, but in cases where some system architect has decried that some data structure adheres to ISO 8601, then that data structure should indeed be interpreted very pedantically with reference to the standard. There is an interesting issue parsing free format strings since an ISO 8601 compliant substring might be preceded by some sequence of characters (perhaps not even ASCII) that are non-compliant, or indeed it might be followed by some sequence of characters - such as a 'Z' - with an ambiguous meaning, e.g.: 2009-02-09T19:37:57 Does the Z belong to the ISO substring? There are other similar edge cases - for instance, are the date and time tied together atomically at all? On the other hand, if you state that a field must represent only ISO 8601 compliant values, then the meaning of the Z is controlled. Rob From phk at phk.freebsd.dk Mon Feb 9 14:48:49 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 09 Feb 2009 19:48:49 +0000 Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? In-Reply-To: Your message of "Mon, 09 Feb 2009 15:13:11 -0400." <1234206791.4990804737c5d@webmail.unb.ca> Message-ID: <40291.1234208929@critter.freebsd.dk> In message <1234206791.4990804737c5d at webmail.unb.ca>, "Richard B. Langley" writ es: >> It is not clear to me if the zero meridian have 'N' or >> 'Z' as designator. > >Neither. It is "M." I have a scan of a B&W photo of the painting if anyone is >interested. Of course, (M)eridian :-) I'd be more interested in if you know where the painting is ? I'm probably going to BSDcan in Ottawa again this year, and if it is within range I would like to see it myself. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From ashtongj at comcast.net Mon Feb 9 14:55:06 2009 From: ashtongj at comcast.net (Gerard Ashton) Date: Mon, 9 Feb 2009 14:55:06 -0500 Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? In-Reply-To: Message-ID: Rob Seaman wrote: >Gerard Ashton wrote: > >> Similarly, within ISO 8601, "Z" designates "UTC" and any meaning it >> may have had for most of the 20th century outside that standard is >> irrelevant. >I don't know if I agree with the latter part of the sentence since Z >retains usage outside of ISO 8601, but in cases where some system >architect has decried that some data structure adheres to ISO 8601, >then that data structure should indeed be interpreted very >pedantically with reference to the standard. I agree with Rob. I meant that any meaning "Z" had throughout most of the 20th century, and continues to have in environments where adherence to ISO 8601 is not claimed, is irrelevant. Gerry Ashton From lang at unb.ca Mon Feb 9 15:37:21 2009 From: lang at unb.ca (Richard B. Langley) Date: Mon, 9 Feb 2009 16:37:21 -0400 Subject: [LEAPSECS] ISO 8601 Z designator improper before 1972? In-Reply-To: <40291.1234208929@critter.freebsd.dk> References: <40291.1234208929@critter.freebsd.dk> Message-ID: <1234211841.4990940185da7@webmail.unb.ca> I don't know where the original is now. Did a Google search but couldn't find it. The painting was one of 40 done for the now defunct insurance company, Confederation Life, by Woods, a prolific commercial artist. A fire gutted the Confereration Life building in Toronto in the 1970s. Don't know if the paintings were there or, if they were there, were saved or were destroyed. But, apparently, there is a print at Cambridge University Prints also at the Royal Alberta Museum While searching, came across this which used to run as a "public education service" on Canadian TV. -- Richard Langley Quoting Poul-Henning Kamp : > In message <1234206791.4990804737c5d at webmail.unb.ca>, "Richard B. Langley" writ > es: > > >> It is not clear to me if the zero meridian have 'N' or > >> 'Z' as designator. > > > >Neither. It is "M." I have a scan of a B&W photo of the painting if anyone is > >interested. > > Of course, (M)eridian :-) > > I'd be more interested in if you know where the painting is ? > > I'm probably going to BSDcan in Ottawa again this year, and if it is within > range I would like to see it myself. > > Poul-Henning > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at 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 at leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs > =============================================================================== Richard B. Langley E-mail: lang at unb.ca Geodetic Research Laboratory Web: http://www.unb.ca/GGE/ Dept. of Geodesy and Geomatics Engineering Phone: +1 506 453-5142 University of New Brunswick Fax: +1 506 453-4943 Fredericton, N.B., Canada E3B 5A3 Fredericton? Where's that? See: http://www.city.fredericton.nb.ca/ =============================================================================== From neal at bcn.boulder.co.us Fri Feb 13 17:26:33 2009 From: neal at bcn.boulder.co.us (Neal McBurnett) Date: Fri, 13 Feb 2009 15:26:33 -0700 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 Message-ID: <20090213222633.GF7622@feynman> In an hour comes another fun moment in time: Unix time_t reaches 1234567890 seconds. That's at 23:31:30 UTC the night between friday February 13th and saturday 14th. Here are some related pages: http://broadcast.oreilly.com/2009/02/unixs-magical-moment-as-foreto.html Events: http://www.1234567890day.com/ A nice countdown: http://redhorse.se/cs/time.html Twitter: http://twitter.com/utcwatch But I'm sad that most everyone is forgetting the 24 leap seconds that will have passed by then, ignored by the kernel.... http://en.wikipedia.org/wiki/Leap_second So I'll also celebrate the passing of 1234567890 UTC seconds since January 1 1970, 00:00, which is 24 seconds earlier. As Steve so carefully describes, because of the "rubber seconds" in use before 1972 and other issues there are actually several other interpretations of the number of seconds since 1970 - see these links: http://www.ucolick.org/~sla/leapsecs/onlinebib.html#POSIX http://www.ucolick.org/~sla/leapsecs/onlinebib.html#POSIXepoch And the legal situation is different still, see: http://www.ucolick.org/~sla/leapsecs/epochtime.html Cheers! Or as we say in Esperanto, "Sanon!" Neal McBurnett http://neal.mcburnett.org/ From zefram at fysh.org Fri Feb 13 18:25:26 2009 From: zefram at fysh.org (Zefram) Date: Fri, 13 Feb 2009 23:25:26 +0000 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090213222633.GF7622@feynman> References: <20090213222633.GF7622@feynman> Message-ID: <20090213232526.GI2263@fysh.org> Neal McBurnett wrote: >So I'll also celebrate the passing of 1234567890 UTC seconds >since January 1 1970, 00:00, which is 24 seconds earlier. To be precise, you must also include the leap at the end of 1971, of 10775800/100000003 UTC seconds. That's 0.107758 TAI seconds, at the then-prevailing rate of 1.00000003 TAI seconds per UTC second. (All these numbers exact.) It is somewhat more meaningful to treat Unix time as based on vague UT, rather than specifically UTC. The Unix time 1234567890 will, to within a second, mark 1234567890 UT1 seconds since 1970-01-01T00:00:00 UT1. -zefram From magnus at rubidium.dyndns.org Fri Feb 13 20:42:48 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 14 Feb 2009 02:42:48 +0100 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090213232526.GI2263@fysh.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> Message-ID: <49962198.70802@rubidium.dyndns.org> Zefram skrev: > Neal McBurnett wrote: >> So I'll also celebrate the passing of 1234567890 UTC seconds >> since January 1 1970, 00:00, which is 24 seconds earlier. > > To be precise, you must also include the leap at the end of 1971, > of 10775800/100000003 UTC seconds. That's 0.107758 TAI seconds, at > the then-prevailing rate of 1.00000003 TAI seconds per UTC second. > (All these numbers exact.) The reference epoch at MJD 40587. This can be used with this table http://hpiers.obspm.fr/eop-pc/earthor/utc/TAI-UTC_tab.html to convert into the TAI-UTC difference. 1966 Jan. 1 - 1968 Feb. 1 4.313 170 0s + (MJD - 39 126) x 0.002592s 1968 Feb. 1 - 1972 Jan. 1 4.213 170 0s + "" Thus, the TAI-UTC difference was 4.213170 + (40587-39126) x 0.002592s = 8.000082 s. Quite close but no cigar to 8 s sharp. 82 us off. > It is somewhat more meaningful to treat Unix time as based on vague UT, > rather than specifically UTC. The Unix time 1234567890 will, to within > a second, mark 1234567890 UT1 seconds since 1970-01-01T00:00:00 UT1. Well, it depends on what you actually mean by "Unix time". The original definition puts the reference epoch to 00:00:00 GMT. Then you can make a pick on what seconds you want to use... and then you have the Posix time... which maps UTC to time_t... Actually, if we interprent GMT as UT1, then the above calculation is again wrong as it gives the UTC but not UT1... so we need to dig up some pretty old Circular B papers... which does not seem to be online... So depending on which interpretation you choose... I see some 3-4 different times occuring. The spread amongst them is about 26 s or so. Cheers, Magnus From zefram at fysh.org Sat Feb 14 04:55:28 2009 From: zefram at fysh.org (Zefram) Date: Sat, 14 Feb 2009 09:55:28 +0000 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <49962198.70802@rubidium.dyndns.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> Message-ID: <20090214095528.GJ2263@fysh.org> Magnus Danielson wrote: >Thus, the TAI-UTC difference was 4.213170 + (40587-39126) x 0.002592s = >8.000082 s. Yes. This lets you calculate the number of *TAI* seconds since the Unix epoch. There were 63072001.999918 TAI seconds (exactly) in UTC's version of 1970 and 1971 together. >So depending on which interpretation you choose... I see some 3-4 >different times occuring. The spread amongst them is about 26 s or so. I think it's clear that Unix time has the well-established naive mapping to some form of UT. You can pick UT1 or UTC, giving answers that differ by a fraction of a second. Anything that secularly counts other than 86400 per UT day isn't Unix time: this includes counting either UTC or TAI seconds. -zefram From magnus at rubidium.dyndns.org Sat Feb 14 08:12:56 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 14 Feb 2009 14:12:56 +0100 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090214095528.GJ2263@fysh.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> Message-ID: <4996C358.6020502@rubidium.dyndns.org> Zefram skrev: > Magnus Danielson wrote: >> Thus, the TAI-UTC difference was 4.213170 + (40587-39126) x 0.002592s = >> 8.000082 s. > > Yes. This lets you calculate the number of *TAI* seconds since the > Unix epoch. There were 63072001.999918 TAI seconds (exactly) in UTC's > version of 1970 and 1971 together. Indeed. This is useful for those believing in SI/TAI seconds for as the second distance of time_t, their reference epoch is inconveniently offset in this fashion, making them have an offset of 25,999918 s from POSIX (right now - propper reference scale should be TAI). Those believing in rubber seconds up to 1972 and then SI/TAI seconds from that will get the more convenient 10 s offset from 1 Jan 1972, making them having an offset of 24 s from POSIX. Using the current POSIX definition UTC is mapped into time_t, skipping leap seconds but otherwise maintaining UTC distances. It will thus honour the rubber seconds (after the fact). However, celebrating 1234567890 seconds of time_t makes no sense at the time that time_t reads 1234567890 since it is not the number of seconds from the reference epoch, it is a form of "mock seconds" to make the scales fit. 24 leap seconds have shifted the offset of the scale and 1,999918 rubber seconds too. We could then add that original reference epoch was given in GMT, which should be interpreted as UT1. I have not found any circular B online covering 1 Jan 1970, but using that information we could deliver the UT1-UTC and UT1-TAI offsets for the reference epoch for the pre-POSIX people. >> So depending on which interpretation you choose... I see some 3-4 >> different times occuring. The spread amongst them is about 26 s or so. > > I think it's clear that Unix time has the well-established naive mapping > to some form of UT. You can pick UT1 or UTC, giving answers that differ > by a fraction of a second. Anything that secularly counts other than > 86400 per UT day isn't Unix time: this includes counting either UTC or > TAI seconds. It is naive yes... Cheers, Magnus From seaman at noao.edu Sat Feb 14 10:24:30 2009 From: seaman at noao.edu (Rob Seaman) Date: Sat, 14 Feb 2009 08:24:30 -0700 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <4996C358.6020502@rubidium.dyndns.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> Message-ID: <36B15059-9830-4DF5-87B2-BB1BBF679320@noao.edu> Magnus Danielson wrote: > However, celebrating 1234567890 seconds of time_t makes no sense at > the time that time_t reads 1234567890 since it is not the number of > seconds from the reference epoch, it is a form of "mock seconds" to > make the scales fit. Is that really a good reason not to celebrate a silly milestone on a Friday afternoon? :-) This is like the inane debate about whether the millennium was New Year's Eve 1999 or 2000. The real answer is to celebrate both - as a reason to have a most excellent party, that is. If forced to choose, pick the earlier event since that preserves the second opportunity as well. >> I think it's clear that Unix time has the well-established naive >> mapping to some form of UT. You can pick UT1 or UTC, giving >> answers that differ by a fraction of a second. Anything that >> secularly counts other than 86400 per UT day isn't Unix time: this >> includes counting either UTC or TAI seconds. > > It is naive yes... From Dictionary.com: naive -adjective 1. having or showing unaffected simplicity of nature or absence of artificiality; unsophisticated; ingenuous. 2. having or showing a lack of experience, judgment, or information; credulous: She's so naive she believes everything she reads. He has a very naive attitude toward politics. 3. having or marked by a simple, unaffectedly direct style reflecting little or no formal training or technique: valuable naive 19th-century American portrait paintings. 4. not having previously been the subject of a scientific experiment, as an animal. The little dig here, of course, is that Zefram means naive with a definition something like #1 and Magnus is asserting #2. However - there is real value in preserving simplicity of design as with definition #3. Zefram's explanation is succinct and accurate. UTC is a flavor of universal time. UT is phase-locked to the Sun. Meanwhile, while we chat amiably, the ITU is treating the whole world like #4. Rob From imp at bsdimp.com Sat Feb 14 11:17:47 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 14 Feb 2009 09:17:47 -0700 (MST) Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090214095528.GJ2263@fysh.org> References: <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> Message-ID: <20090214.091747.-726378443.imp@bsdimp.com> In message: <20090214095528.GJ2263 at fysh.org> Zefram writes: : Magnus Danielson wrote: : >Thus, the TAI-UTC difference was 4.213170 + (40587-39126) x 0.002592s = : >8.000082 s. : : Yes. This lets you calculate the number of *TAI* seconds since the : Unix epoch. There were 63072001.999918 TAI seconds (exactly) in UTC's : version of 1970 and 1971 together. I'd phrase these like so: UTC's 1970 and 1971 together had 63072001.999918 SI seconds (exactly). or The TAI time scale ticked 63072001.999918 SI seconds (exactly), while UTC ticked 63072000 "seconds" between 00:00:00 1970-01-01 UTC and 00:00:00 1972-01-01 UTC. Or at least I think that's a way of saying it that's less ambiguous. : >So depending on which interpretation you choose... I see some 3-4 : >different times occuring. The spread amongst them is about 26 s or so. : : I think it's clear that Unix time has the well-established naive mapping : to some form of UT. You can pick UT1 or UTC, giving answers that differ : by a fraction of a second. Anything that secularly counts other than : 86400 per UT day isn't Unix time: this includes counting either UTC or : TAI seconds. Unix's time_t is almost universally implemented these days as one of the following two formula: 63072000 + SI ticks since 1972 - TAI_UTC_Offset while a minority of systems with the 'right' time zones try to implement the following: 63072000 + SI ticks since 1972 but often times the former is often really implemented as: 63072000 + SI ticks since 1972 - TAI_UT_Offset + small_delta because the leap second file configuration is botched by incompetent distros or system admins. I know this isn't the "definition" of time_t, but it is its practical realization and a way that mathematically expresses the "simplification of UTC" that nearly everybody does today that igonres the rubber seconds prior to 1972. And yes, I do agree that the minority of systems that actually track UT1 will only differ by some small fraction of a second from UTC. Warner From magnus at rubidium.dyndns.org Sat Feb 14 12:02:21 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 14 Feb 2009 18:02:21 +0100 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <36B15059-9830-4DF5-87B2-BB1BBF679320@noao.edu> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> <36B15059-9830-4DF5-87B2-BB1BBF679320@noao.edu> Message-ID: <4996F91D.9080605@rubidium.dyndns.org> Dear Rob, Rob Seaman skrev: > Magnus Danielson wrote: > >> However, celebrating 1234567890 seconds of time_t makes no sense at >> the time that time_t reads 1234567890 since it is not the number of >> seconds from the reference epoch, it is a form of "mock seconds" to >> make the scales fit. > > Is that really a good reason not to celebrate a silly milestone on a > Friday afternoon? :-) Yes, since it occured evening time here, in my time-zone... all 4 events... you could have crammed them into one party. > This is like the inane debate about whether the millennium was New > Year's Eve 1999 or 2000. The real answer is to celebrate both - as a > reason to have a most excellent party, that is. If forced to choose, > pick the earlier event since that preserves the second opportunity as well. Whatever arbitrary numerology cause you to be happy, go for it. OK? It's like the leap second. I notice that they go by, but I actually spent the time seeing a good movie and find it in the logs afterwards. The point here however is to point out that time_t is not necessarily what you may think it is. >>> I think it's clear that Unix time has the well-established naive >>> mapping to some form of UT. You can pick UT1 or UTC, giving answers >>> that differ by a fraction of a second. Anything that secularly >>> counts other than 86400 per UT day isn't Unix time: this includes >>> counting either UTC or TAI seconds. >> >> It is naive yes... > > > From Dictionary.com: > > naive -adjective > 1. having or showing unaffected simplicity of nature or absence of > artificiality; unsophisticated; ingenuous. > 2. having or showing a lack of experience, judgment, or information; > credulous: She's so naive she believes everything she reads. He has a > very naive attitude toward politics. > 3. having or marked by a simple, unaffectedly direct style > reflecting little or no formal training or technique: valuable naive > 19th-century American portrait paintings. > 4. not having previously been the subject of a scientific > experiment, as an animal. > > The little dig here, of course, is that Zefram means naive with a > definition something like #1 and Magnus is asserting #2. I think you should consider that my statement covered several senses as listed above rather than asserting that I was only meaning one of them. Be careful not to act as a judge of what others actually meant, you yourself might have not fully understood what they meant, but you can have an interpretation of what you think they meant. Also, none of us consulted the particular dictionary that you choose and selected some particular meaning of the word naive, so explaining what we said by using that method is not particularly helpful. > However - there is real value in preserving simplicity of design as with > definition #3. Zefram's explanation is succinct and accurate. UTC is a > flavor of universal time. UT is phase-locked to the Sun. The definition of UNIX time_t has varied. There have been a wish to keep things simple and for "most purposes" useful. The POSIX time_t is a compromise with side-effects. Regardless of which time_t definition the side-effects cause head-aches and we need to be aware of them. To cure some of these additional interpretations can be found. The time_t is not as good time-scale as people imagine and this we need to know and deal with it. Darn, I just discovered yeat another interpretation of that the time_t could be... isn't very helpful, now is it? While simplicity is a beautiful thing, over-simplicity may cause horrendously complex problems at a later stage. I think time_t suffers from this to some degree. > Meanwhile, while we chat amiably, the ITU is treating the whole world > like #4. Well, if you mean that we have not experienced the stop of leaps seconds and that we should not be frigthened by experience the stop of leap seconds from experience it the first time, then I think I agree with you, since this is how that form of the term naive is used for animals during treatment, their use is to be interpreted as "they are just to become experienced, so they will no longer be naive". The naiveness lies in the lack of experience of what to come from say firing the stun-gun and is mainly used in a concerned way. If you meant that ITU is treating the rest of a world as a experiment as such I think it is not covered by that meaning. What meaning you had interpreted to naive in the #4 sense I am still not quite sure, but I think I have some guesses from your previous posts, yeat again I cannot be completely sure. Cheers, Magnus From seaman at noao.edu Sat Feb 14 12:50:42 2009 From: seaman at noao.edu (Rob Seaman) Date: Sat, 14 Feb 2009 10:50:42 -0700 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <4996F91D.9080605@rubidium.dyndns.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> <36B15059-9830-4DF5-87B2-BB1BBF679320@noao.edu> <4996F91D.9080605@rubidium.dyndns.org> Message-ID: <9CACC262-4599-41FF-8377-E895FF2079A4@noao.edu> Magnus Danielson wrote: > It's like the leap second. I notice that they go by, but I actually > spent the time seeing a good movie and find it in the logs afterwards. That is kind of the point. > Be careful not to act as a judge of what others actually meant, you > yourself might have not fully understood what they meant, Indeed. For instance, we have no clue what the ITU is really trying to do. Since the ITU isn't bothering to justify their behavior with things like plans and risk analyses, we're left to interpret tea leaves. > The time_t is not as good time-scale as people imagine and this we > need to know and deal with it. I don't think anybody here imagines time_t to be very well designed. There is nothing to disagree with in either your or Zefram's messages. > The naiveness lies in the lack of experience of what to come from > say firing the stun-gun and is mainly used in a concerned way. Ah! That's what the ITU is trying to do! Rob From zefram at fysh.org Sat Feb 14 12:57:34 2009 From: zefram at fysh.org (Zefram) Date: Sat, 14 Feb 2009 17:57:34 +0000 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <4996C358.6020502@rubidium.dyndns.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> Message-ID: <20090214175734.GL2263@fysh.org> Magnus Danielson wrote: >Indeed. This is useful for those believing in SI/TAI seconds for as the >second distance of time_t, their reference epoch is inconveniently >offset in this fashion, making them have an offset of 25,999918 s from >POSIX (right now - propper reference scale should be TAI). Yes. >Those believing in rubber seconds up to 1972 and then SI/TAI seconds >from that will get the more convenient 10 s offset from 1 Jan 1972, >making them having an offset of 24 s from POSIX. No, if you're doing this then you must include the irregular leap. The current offset is about 24.107757997 s, and does not have a terminating decimal representation. (This is the counting-UTC-seconds way.) I believe some people do do the 24 s offset that you suggest, however. I think it's through ignorance of the rubber-seconds era and its leaps. These people are effectively using an epoch of 1972-01-01T00:00:00 UTC = 63072000. There's no clean description of what they're counting since 1970. If doing this then it seems more consistent for pre-1972 timestamps to count back in TAI seconds, but in practice I think a vague-UT pre-1972 timescale gets grafted onto the TAI-synched post-1972 timescale. Bit of a mess. >1234567890 seconds of time_t makes no sense at the time that time_t >reads 1234567890 since it is not the number of seconds from the >reference epoch, it is a form of "mock seconds" to make the scales fit. Yes. This is sometimes succinctly described as counting "non-leap seconds since the epoch". -zefram From zefram at fysh.org Sat Feb 14 13:06:59 2009 From: zefram at fysh.org (Zefram) Date: Sat, 14 Feb 2009 18:06:59 +0000 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090214.091747.-726378443.imp@bsdimp.com> References: <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <20090214.091747.-726378443.imp@bsdimp.com> Message-ID: <20090214180659.GM2263@fysh.org> M. Warner Losh wrote: >I'd phrase these like so: > >UTC's 1970 and 1971 together had 63072001.999918 SI seconds (exactly). That's not quite true. They had that many *TAI* seconds, but TAI seconds are not equal to SI seconds. TAI is an imperfect realisation of the SI second. UTC(TT) is a mildly interesting notion. >The TAI time scale ticked 63072001.999918 SI seconds (exactly), while >UTC ticked 63072000 "seconds" between 00:00:00 1970-01-01 UTC and >00:00:00 1972-01-01 UTC. UTC ticked some 63072000.107757997 seconds in that time. Of greater relevance is that UTC ticked exactly 730 days (as you indicate). So many nits to pick. -zefram From magnus at rubidium.dyndns.org Sat Feb 14 14:11:20 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 14 Feb 2009 20:11:20 +0100 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <9CACC262-4599-41FF-8377-E895FF2079A4@noao.edu> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> <36B15059-9830-4DF5-87B2-BB1BBF679320@noao.edu> <4996F91D.9080605@rubidium.dyndns.org> <9CACC262-4599-41FF-8377-E895FF2079A4@noao.edu> Message-ID: <49971758.60409@rubidium.dyndns.org> Rob, Rob Seaman skrev: > Magnus Danielson wrote: > >> It's like the leap second. I notice that they go by, but I actually >> spent the time seeing a good movie and find it in the logs afterwards. > > That is kind of the point. > >> Be careful not to act as a judge of what others actually meant, you >> yourself might have not fully understood what they meant, > > Indeed. For instance, we have no clue what the ITU is really trying to > do. Since the ITU isn't bothering to justify their behavior with things > like plans and risk analyses, we're left to interpret tea leaves. The particular study group of ITU-R (and not the whole of ITU) is of interest here as to what "they" are attempting to study and achieve. As with any standard group I don't think they have one single unified idea and purpose, but rather they have a particular agenda they are studying and I assume they perceive it as an open process within their context. We have only a fractional access to the contributions and discussions. >> The time_t is not as good time-scale as people imagine and this we >> need to know and deal with it. > > I don't think anybody here imagines time_t to be very well designed. > There is nothing to disagree with in either your or Zefram's messages. Well, the celebration of a particular datum of a particular time-scale which is ambigous shows that people are not aware of these issues. Maybe most of the people subscribing to this particular list is aware of it, but there is sufficiently many that does not know of it. >> The naiveness lies in the lack of experience of what to come from say >> firing the stun-gun and is mainly used in a concerned way. > > Ah! That's what the ITU is trying to do! I take this as a humoristic attempt to denote what the particular study group of ITU-R is working on, correct? Cheers, Magnus From imp at bsdimp.com Sat Feb 14 14:26:47 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 14 Feb 2009 12:26:47 -0700 (MST) Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090214175734.GL2263@fysh.org> References: <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> <20090214175734.GL2263@fysh.org> Message-ID: <20090214.122647.-1183027946.imp@bsdimp.com> In message: <20090214175734.GL2263 at fysh.org> Zefram writes: : I believe some people do do the 24 s offset that you suggest, however. : I think it's through ignorance of the rubber-seconds era and its leaps. : These people are effectively using an epoch of 1972-01-01T00:00:00 UTC : = 63072000. There's no clean description of what they're counting since : 1970. If doing this then it seems more consistent for pre-1972 timestamps : to count back in TAI seconds, but in practice I think a vague-UT pre-1972 : timescale gets grafted onto the TAI-synched post-1972 timescale. Bit of : a mess. It is a useful engineering approximation. Oh, wait, you said a bit of a mess already... Warner From seaman at noao.edu Sat Feb 14 14:51:19 2009 From: seaman at noao.edu (Rob Seaman) Date: Sat, 14 Feb 2009 12:51:19 -0700 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <49971758.60409@rubidium.dyndns.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> <36B15059-9830-4DF5-87B2-BB1BBF679320@noao.edu> <4996F91D.9080605@rubidium.dyndns.org> <9CACC262-4599-41FF-8377-E895FF2079A4@noao.edu> <49971758.60409@rubidium.dyndns.org> Message-ID: Magnus Danielson wrote: > We have only a fractional access to the contributions and discussions. Indeed. One remains skeptical, however, that there is a hidden systems engineering management plan appropriate to the task before them. > I take this as a humoristic attempt to denote what the particular > study group of ITU-R is working on, correct? Um - yes. Rob From magnus at rubidium.dyndns.org Sat Feb 14 14:57:09 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 14 Feb 2009 20:57:09 +0100 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090214175734.GL2263@fysh.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> <20090214175734.GL2263@fysh.org> Message-ID: <49972215.5000307@rubidium.dyndns.org> Zefram skrev: > Magnus Danielson wrote: >> Indeed. This is useful for those believing in SI/TAI seconds for as the >> second distance of time_t, their reference epoch is inconveniently >> offset in this fashion, making them have an offset of 25,999918 s from >> POSIX (right now - propper reference scale should be TAI). > > Yes. > >> Those believing in rubber seconds up to 1972 and then SI/TAI seconds >> from that will get the more convenient 10 s offset from 1 Jan 1972, >> making them having an offset of 24 s from POSIX. > > No, if you're doing this then you must include the irregular leap. Sorry, I think you over-interpret a poorly articulated formulation of mine. If you think according to "Honour the UTC definition from 1970 to 1972 and then the new leap-second based UTC definition from 1972 up to current time" then I think you should come to the same conclusion as I do. The honouring of the UTC definitions includes the leaps in offset both during the pre-1972 definition as well as at the time of change to the new standard. > The current offset is about 24.107757997 s, and does not have a terminating > decimal representation. (This is the counting-UTC-seconds way.) I do not understand what that number comes from. Does not match what I meant at least, so you need to describe what it means. > I believe some people do do the 24 s offset that you suggest, however. > I think it's through ignorance of the rubber-seconds era and its leaps. So true. > These people are effectively using an epoch of 1972-01-01T00:00:00 UTC > = 63072000. There's no clean description of what they're counting since > 1970. If doing this then it seems more consistent for pre-1972 timestamps > to count back in TAI seconds, but in practice I think a vague-UT pre-1972 > timescale gets grafted onto the TAI-synched post-1972 timescale. Bit of > a mess. It is a bit of a mess. Honouring the pre-1972 UTC definition for the pre-1972 era makes sense as it allows for a practical solution at least, as only integer offsets is involved. The POSIX re-defintion patches the apparent drift between time_t and UTC datums caused by leap seconds, but that is a post-1972 era issue and does not fully explains the pre-1972 era behaviour, but could be interpreted to honour the pre-1972 UTC definition, but then the reference epoch is not occuring at the same time as the original UNIX GMT defined epoch. >> 1234567890 seconds of time_t makes no sense at the time that time_t >> reads 1234567890 since it is not the number of seconds from the >> reference epoch, it is a form of "mock seconds" to make the scales fit. > > Yes. This is sometimes succinctly described as counting "non-leap > seconds since the epoch". Well... that only explains the behaviour in the post-1972 era, where as it does not really help for the pre-1972 era where leap seconds was not used, so even that wording does not sufficiently covers what is happening unfortunately. At 1 Jan 1972 we jumped from 9,892242 to 10 s offset in one fractional step. Before that we had a 3E-8 s/s phase ramp from 8,000082 of 1 Jan 1970. Neither qualify as leap seconds. Cheers, Magnus From magnus at rubidium.dyndns.org Sat Feb 14 15:01:14 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 14 Feb 2009 21:01:14 +0100 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090214180659.GM2263@fysh.org> References: <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <20090214.091747.-726378443.imp@bsdimp.com> <20090214180659.GM2263@fysh.org> Message-ID: <4997230A.6010905@rubidium.dyndns.org> Zefram skrev: > M. Warner Losh wrote: >> I'd phrase these like so: >> >> UTC's 1970 and 1971 together had 63072001.999918 SI seconds (exactly). > > That's not quite true. They had that many *TAI* seconds, but TAI seconds > are not equal to SI seconds. TAI is an imperfect realisation of the > SI second. UTC(TT) is a mildly interesting notion. > >> The TAI time scale ticked 63072001.999918 SI seconds (exactly), while >> UTC ticked 63072000 "seconds" between 00:00:00 1970-01-01 UTC and >> 00:00:00 1972-01-01 UTC. > > UTC ticked some 63072000.107757997 seconds in that time. Of greater > relevance is that UTC ticked exactly 730 days (as you indicate). You mean to say it ticked 93072000.107757997 SI seconds in that time? Notice that we have several "seconds" here so we may need to qualify them as "SI seconds", "TAI seconds" and "UTC seconds" to make language clear for this particular era. > So many nits to pick. Oh yes. Cheers, Magnus From zefram at fysh.org Sat Feb 14 15:10:56 2009 From: zefram at fysh.org (Zefram) Date: Sat, 14 Feb 2009 20:10:56 +0000 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <4997230A.6010905@rubidium.dyndns.org> References: <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <20090214.091747.-726378443.imp@bsdimp.com> <20090214180659.GM2263@fysh.org> <4997230A.6010905@rubidium.dyndns.org> Message-ID: <20090214201056.GO2263@fysh.org> Magnus Danielson wrote: >Zefram skrev: >>UTC ticked some 63072000.107757997 seconds in that time. Of greater >>relevance is that UTC ticked exactly 730 days (as you indicate). > >You mean to say it ticked 93072000.107757997 SI seconds in that time? No. In that time there were exactly 63072001.999918 TAI seconds; the number of SI seconds is very close to that. But there were about 93072000.107757997 *UTC* seconds (exactly 63072000+10775800/100000003 UTC seconds, in fact). >Notice that we have several "seconds" here so we may need to qualify >them as "SI seconds", "TAI seconds" and "UTC seconds" to make language >clear for this particular era. Yes. Where I've said "YYY ticked Z.Z seconds" I meant, precisely, "there were Z.Z YYY seconds". -zefram From zefram at fysh.org Sat Feb 14 15:26:10 2009 From: zefram at fysh.org (Zefram) Date: Sat, 14 Feb 2009 20:26:10 +0000 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <49972215.5000307@rubidium.dyndns.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> <20090214175734.GL2263@fysh.org> <49972215.5000307@rubidium.dyndns.org> Message-ID: <20090214202610.GP2263@fysh.org> Magnus Danielson wrote: >Sorry, I think you over-interpret a poorly articulated formulation of >mine. If you think according to "Honour the UTC definition from 1970 to >1972 and then the new leap-second based UTC definition from 1972 up to >current time" then I think you should come to the same conclusion as I >do. I was thinking precisely in terms of using UTC in both eras, counting UTC seconds. Thus I count UTC's leaps of both eras. >Zefram skrev: >>The current offset is about 24.107757997 s, and does not have a terminating >>decimal representation. (This is the counting-UTC-seconds way.) > >I do not understand what that number comes from. Does not match what I >meant at least, so you need to describe what it means. The 24 corresponds to the 24 positive leap seconds since 1972. The remainder corresponds to pre-1972 leaps. In fact there is exactly one such leap after the Unix epoch, and that is the final one at the end of 1971 which brought UTC seconds into alignment with TAI seconds. The duration of that leap was exactly 0.107758 TAI seconds. At the then-prevailing rate of 1 UTC second = 1.00000003 TAI seconds, the duration of the leap was exactly 10775800/100000003 UTC seconds, or approximately 0.107757997 UTC seconds. The number of elapsed UTC seconds from 1972-01-01T00:00:00 UTC to any UTC midnight in 2009 is exactly 86400*(number of elapsed days) + 24 + 10775800/100000003. It seems clear to me, but I studied it quite closely to write the Perl module Time::UTC (which is what I've used to extract some of these numbers). I guess it's trickier than it looks. >It is a bit of a mess. Honouring the pre-1972 UTC definition for the >pre-1972 era makes sense as it allows for a practical solution at least, >as only integer offsets is involved. ... >it does not really help for the pre-1972 era where leap seconds was not >used, You seem to think there were no leaps in UTC before 1972. Evidently that's why you get confused about the fractional number of leap seconds. >At 1 Jan 1972 we jumped from 9,892242 to 10 s offset in one fractional >step. But this is a reference to the irregular leap. > Before that we had a 3E-8 s/s phase ramp from 8,000082 of 1 Jan >1970. Neither qualify as leap seconds. The frequency offset isn't a leap, because it doesn't give UTC days an irregular number of UTC seconds. But the 1971-12-31 leap, and earlier leaps that were mostly of 0.1 TAI seconds, certainly are (fractional) leap seconds. When I first read about the rubber seconds era, I got the impression that it was done solely by frequency offsets, with no leaps. How much easier would our lives have been if that were the case? -zefram From magnus at rubidium.dyndns.org Sat Feb 14 16:02:44 2009 From: magnus at rubidium.dyndns.org (Magnus Danielson) Date: Sat, 14 Feb 2009 22:02:44 +0100 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090214202610.GP2263@fysh.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> <20090214175734.GL2263@fysh.org> <49972215.5000307@rubidium.dyndns.org> <20090214202610.GP2263@fysh.org> Message-ID: <49973174.1080502@rubidium.dyndns.org> Zefram skrev: > Magnus Danielson wrote: >> Sorry, I think you over-interpret a poorly articulated formulation of >> mine. If you think according to "Honour the UTC definition from 1970 to >> 1972 and then the new leap-second based UTC definition from 1972 up to >> current time" then I think you should come to the same conclusion as I >> do. > > I was thinking precisely in terms of using UTC in both eras, counting > UTC seconds. Thus I count UTC's leaps of both eras. > >> Zefram skrev: >>> The current offset is about 24.107757997 s, and does not have a terminating >>> decimal representation. (This is the counting-UTC-seconds way.) >> I do not understand what that number comes from. Does not match what I >> meant at least, so you need to describe what it means. > > The 24 corresponds to the 24 positive leap seconds since 1972. > The remainder corresponds to pre-1972 leaps. In fact there is exactly > one such leap after the Unix epoch, and that is the final one at the > end of 1971 which brought UTC seconds into alignment with TAI seconds. > The duration of that leap was exactly 0.107758 TAI seconds. At the > then-prevailing rate of 1 UTC second = 1.00000003 TAI seconds, the > duration of the leap was exactly 10775800/100000003 UTC seconds, or > approximately 0.107757997 UTC seconds. I gathered that eventually and it makes perfect sense. You only made a very brief discussion over it so I did not get the right triggers. The leap in TAI-UTC offset as measured in TAI seconds needs to be converted into UTC seconds. However... is it the UTC seconds of the previous era or the new era? It's a singularity so you can't use the slope of the previous era, infact the scope of that era goes to but does not include the UTC time of 1 Jan 1972 00:00:00, so the jump can not be included in that era. So I think your calculation is actually wrong in this respect and that 63072000.107758 UTC seconds is the time that has passed. > The number of elapsed UTC seconds from 1972-01-01T00:00:00 UTC to any > UTC midnight in 2009 is exactly 86400*(number of elapsed days) + 24 + > 10775800/100000003. I am starting to disagree about the last term there. > It seems clear to me, but I studied it quite closely to write the Perl > module Time::UTC (which is what I've used to extract some of these > numbers). I guess it's trickier than it looks. It is tricky... I think you need to explain how you interpret the range-definitions as I interpret them a little bit different. >> It is a bit of a mess. Honouring the pre-1972 UTC definition for the >> pre-1972 era makes sense as it allows for a practical solution at least, >> as only integer offsets is involved. > ... >> it does not really help for the pre-1972 era where leap seconds was not >> used, > > You seem to think there were no leaps in UTC before 1972. Evidently > that's why you get confused about the fractional number of leap seconds. No, I know there is leaps, but no leap seconds. There are several fractional second leaps. I was only challangeing the wording to denote "leap seconds" to fully disregard the shifts and ramps there is. >> At 1 Jan 1972 we jumped from 9,892242 to 10 s offset in one fractional >> step. > > But this is a reference to the irregular leap. Yes, but you confuse my separation of leaps with leaps though the use of the leap second mechanism in which you jump integer seconds. >> Before that we had a 3E-8 s/s phase ramp from 8,000082 of 1 Jan >> 1970. Neither qualify as leap seconds. > > The frequency offset isn't a leap, because it doesn't give UTC days an > irregular number of UTC seconds. But the 1971-12-31 leap, and earlier > leaps that were mostly of 0.1 TAI seconds, certainly are (fractional) > leap seconds. Which is also what I wanted to say. When going back to 1970-01-01T00:00:00Z and then counting from that, just disregarding leap seconds only helps us back to what happend since 1972-01-01T00:00:00Z since only since then the leap seconds have been used as an adjustment mechanism. Previous to that a combination of time and frequency offsets was used, but I do not call them leap seconds... Also, the leap was on 1972-01-01T00:00:00, which is why it should not be included in the 30 ppb frequency era. > When I first read about the rubber seconds era, I got the impression > that it was done solely by frequency offsets, with no leaps. How much > easier would our lives have been if that were the case? Much. Cheers, Magnus From zefram at fysh.org Sat Feb 14 16:45:28 2009 From: zefram at fysh.org (Zefram) Date: Sat, 14 Feb 2009 21:45:28 +0000 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <49973174.1080502@rubidium.dyndns.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> <20090214175734.GL2263@fysh.org> <49972215.5000307@rubidium.dyndns.org> <20090214202610.GP2263@fysh.org> <49973174.1080502@rubidium.dyndns.org> Message-ID: <20090214214528.GQ2263@fysh.org> Magnus Danielson wrote: >leap in TAI-UTC offset as measured in TAI seconds needs to be converted >into UTC seconds. However... is it the UTC seconds of the previous era >or the new era? It's a singularity so you can't use the slope of the >previous era, This is an issue that I had to resolve to write Time::UTC. From examining tai-utc.dat and pushing the numbers around, I came to the conclusion that the model of UTC is consistently that: * leaps occur by adding or removing (fractional) seconds at the end of a UTC day * the duration of a leap is always a round (or, at least, terminating decimal) number of TAI seconds * the duration of a UTC second is likewise always a terminating decimal number of TAI seconds * discontinuities in TAI-UTC offsets (which result from leaps) occur precisely at the boundary between UTC days * frequency shifts in UTC also occur precisely at the boundary between UTC days To get 86400.107758 UTC seconds in 1971-12-31, you would have to suppose that the frequency change occurred at 23:59:60.000, and that UTC then ticked at the same frequency as TAI for 0.107758 seconds until 1972-01-01T00:00:00. I don't see anything indicating that the frequency shift and discontinuity of TAI-UTC (the end of the leap) occurred at different instants. tai-utc.dat shows the two as one event. I suppose my comments about the TAI-UTC difference deserve some explanation. utc-tai.dat handles dates in terms of JD and (equivalently) MJD, but describes the calculation of the relationship between TAI and UTC in terms of a difference in seconds. In a strict 86400-seconds-per-day timescale, such as TAI, MJD and seconds are trivially interconvertible, but MJD doesn't quite work right with UTC. I determined that the MJDs given in tai-utc.dat actually refer to UTC, not TAI. Firstly, the boundary dates given are exact midnights according to the MJD, and as we know leaps occur at midnight UTC. Secondly, calculating this way shows that at the frequency shifts in the rubber-seconds era, other than the final shift at the end of 1971, there was no simultaneous leap. 1961-12-31, for example, had exactly 86400 UTC seconds. To determine the MJD of a UTC time, we can divide up the UTC timestamp into a date and time of day. These can be expressed as an integral MJDN (Modified Julian Day Number) and a fractional number of seconds since midnight (ssm). Then MJD = MJDN + ssm/86400. This is, in fact, the same way that POSIX time is specified to behave. MJD[UTC] thus has funny behaviour at leaps. During a positive leap, ssm>=86400, so MJD[UTC] appears to be in the following day. MJD[UTC] then has a discontinuity at the start of the following day. I then interpret the "TAI-UTC" difference, which is given in seconds, as being 86400 s * (MJD[TAI] - MJD[UTC]). Putting all of this together, this results in UTC seconds on a day with a leap (such as 1964-03-31) having the (expected) same length as the UTC seconds of the preceding day. Any other way of calculating MJD[UTC] would break that. Sorry if the above is difficult to follow. After all this time, having found this to be the only consistent interpretation, I'm having difficulty wrapping my head round other interpretations to explain why they don't work. -zefram From dan at tobias.name Sat Feb 14 19:00:53 2009 From: dan at tobias.name (Daniel R. Tobias) Date: Sat, 14 Feb 2009 19:00:53 -0500 Subject: [LEAPSECS] Pre-1972 UTC Message-ID: <499714E5.12929.10147B2C@dan.tobias.name> Is this stuff all just academic, or does anybody actually have any pre-1972 timestamps (in documents, databases, etc.) for which precise sub-second interpretation is necessary? -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/ From phk at phk.freebsd.dk Sat Feb 14 19:15:18 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun, 15 Feb 2009 00:15:18 +0000 Subject: [LEAPSECS] Pre-1972 UTC In-Reply-To: Your message of "Sat, 14 Feb 2009 19:00:53 EST." <499714E5.12929.10147B2C@dan.tobias.name> Message-ID: <5787.1234656918@critter.freebsd.dk> In message <499714E5.12929.10147B2C at dan.tobias.name>, "Daniel R. Tobias" writes : >Is this stuff all just academic, or does anybody actually have any >pre-1972 timestamps (in documents, databases, etc.) for which precise >sub-second interpretation is necessary? I guess only Dennis, Ken or Brian could be affected, and I doubt they bothered to set their clocks even to second precision. Relevant links: http://www.tuhs.org/ http://cm.bell-labs.com/who/dmr/index.html And in particular: http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From sla at ucolick.org Sat Feb 14 19:17:54 2009 From: sla at ucolick.org (Steve Allen) Date: Sat, 14 Feb 2009 16:17:54 -0800 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090214202610.GP2263@fysh.org> References: <20090213222633.GF7622@feynman> <20090213232526.GI2263@fysh.org> <49962198.70802@rubidium.dyndns.org> <20090214095528.GJ2263@fysh.org> <4996C358.6020502@rubidium.dyndns.org> <20090214175734.GL2263@fysh.org> <49972215.5000307@rubidium.dyndns.org> <20090214202610.GP2263@fysh.org> Message-ID: <20090215001754.GA3000@ucolick.org> The whole subject of an atomically precise Unix epoch is pedantic to the point of irrelevance, for it is another example of the attempt to declare a definitive propleptic time scale in the absence of any such thing being generally available at the time. On 1970-01-01 the authority for world time was BIH, and all of the inputs to them were published in Bulletin Horaire. I'm not sure there was an equivalent publication by the USNO, for prior to the IERS all the international authority was concentrated at BIH, with the other observatories being sovereign for their own countries, and contributors to BIH, but not authoritative beyond that. At that date it was only just dawning on astronomers that VLBI would be a really good way to measure earth orientation. The majority of the input EOP information was from the transit circles. At that date there was no TAI, just BIH's TA. At that date the in-force CCIR reccomendation specified that broadcast time signals should follow UT2. The BIH had been using something referred to as UTC which was supposed to predict UT2, but the Soviets and Chinese had their own version of UTC. Then, as now, the CCIR recommendation was acknowledging that the authority for the maintenance of the time scale was another agency. In 1970 the definition of UT2 was entirely in the hands of BIH, whereas with UTC since 1972 it remains unclear whether the CCIR/ITU-R control the definition of the name UTC per se, or just the definition of the broadcast time signals. At that date the human-audible WWV and WWVH broadcasts in the US were announced as GMT, and I don't know what WWVB or any other national transmissions were doing. And as of 1970-01-01 the TA seconds were of a length systematically shorter than the TAI seconds have been since 1977-01-01. So as of 1970-01-01 the precise time scale means whatever you want it to mean, and the only way to correlate with the time actually available is to dig out the Bulletin Horaire. But at least then the BIH was the place to go for both types of time scales, astronomical and atomic. The way things were split in 1988 leaves us with IERS for the former and BIPM for the latter. The current actions of the ITU-R seem on the whole to be commendable, much more so than the CCIR was in 1970, for the ITU-R is insisting on consensus. It's the delegates to WP7A, their machinations within their own national bodies who approve their positions, and the contributors of position papers who are hard to grok. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From imp at bsdimp.com Sat Feb 14 21:27:26 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat, 14 Feb 2009 19:27:26 -0700 (MST) Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090215001754.GA3000@ucolick.org> References: <49972215.5000307@rubidium.dyndns.org> <20090214202610.GP2263@fysh.org> <20090215001754.GA3000@ucolick.org> Message-ID: <20090214.192726.635729023.imp@bsdimp.com> In message: <20090215001754.GA3000 at ucolick.org> Steve Allen writes: : And as of 1970-01-01 the TA seconds were of a length systematically : shorter than the TAI seconds have been since 1977-01-01. Can you explain this a little bit more, or provide a pointer to the explanation? Thanks for the wonderful information about the state of the art in 1970, and why it doesn't matter if 1234567890 angels are dancing on the head of the pin, or 1234567914 or some crazy number in between. :) Warner From sla at ucolick.org Sat Feb 14 22:05:59 2009 From: sla at ucolick.org (Steve Allen) Date: Sat, 14 Feb 2009 19:05:59 -0800 Subject: [LEAPSECS] Toasting Unix timestamp 1234567890 In-Reply-To: <20090214.192726.635729023.imp@bsdimp.com> References: <49972215.5000307@rubidium.dyndns.org> <20090214202610.GP2263@fysh.org> <20090215001754.GA3000@ucolick.org> <20090214.192726.635729023.imp@bsdimp.com> Message-ID: <20090215030559.GA3712@ucolick.org> On Sat 2009-02-14T19:27:26 -0700, M. Warner Losh hath writ: > In message: <20090215001754.GA3000 at ucolick.org> > Steve Allen writes: > : And as of 1970-01-01 the TA seconds were of a length systematically > : shorter than the TAI seconds have been since 1977-01-01. > > Can you explain this a little bit more, or provide a pointer to the > explanation? Essen's cesium chronometer was running in Teddington in the first half of 1955. The news about this had spread around the time service bureaus really fast. At that date Markowitz at USNO was chair of IAU Comm 31. Before the IAU meeting in that summer Markowitz proposed that the measurements of ephemeris time using the dual-rate moon camera be compared with the cesium using calibrations with the time broadcasts in the US and UK. Before the next IAU meeting in 1958 the US and UK teams had published their calibration of cesium with ephemeris time, and thus was born the atomic second of 9192631770 +/- 20 cycles of the hyperfine transition. The biographies based on interviews with Markowitz indicate that he really was rushing to get this calibration done as soon as possible. In 1957 Rudy Mossbauer identified the lattice effects of gamma ray absorption (and got the Nobel in 1961 only barely after Caltech realized they had better grant him tenure first). By 1960 Pound and Rebka had used the Mossbauer effect to measure the gravitational redshift. As I understand it, the intial versions of atomic time compiled by the BIH simply used all of the contributed measurements of frequency from all of the participating cesium chronometers. Sometime around the early 1970s the comparisons had got good enough to make it evident that a lot of the cesium atoms were running faster than ones at sea level because a lot of the chronomters were a mile up at NBS in Boulder Colorado or at PTB in Bavaria. So in order to be specific about the rate of TAI, it was decided that beginning on 1977-01-01 the frequency of TAI would be reduced by correcting for the height of the chronometers above the geoid. The rate difference was 1e-12. At the 1976 IAU meeting it had finally been decided that the basis for all astronomy had to abandon Newton and adopt Einstein. I think that it was at this meeting where IAU Comm 31 mentioned the impending rate change in TAI, but I'll have to check. I would love to find records of discussions among the astronomers about the impact of changing the rate of TAI as compared with the rate of ephemeris time. In any case it is evident that the uncertainty of the initial measurement of the cesium resonance was more like 2e-9, so this geoid-shift of the rate of TAI was well within that range. Furthermore, extrapolating the rate difference of old TAI and new TAI back to the earliest records of eclipses gives a difference of around 0.1 second, which is clearly below the measurement uncertainty of any sort of calibration that could be made at the dawn of human writing, so it's not like any result could be affected by the change of TAI. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From dot at dotat.at Mon Feb 16 18:22:49 2009 From: dot at dotat.at (Tony Finch) Date: Mon, 16 Feb 2009 23:22:49 +0000 Subject: [LEAPSECS] Pre-1972 UTC In-Reply-To: <5787.1234656918@critter.freebsd.dk> References: <5787.1234656918@critter.freebsd.dk> Message-ID: On Sun, 15 Feb 2009, Poul-Henning Kamp wrote: > Daniel R. Tobias writes: > > > >Is this stuff all just academic, or does anybody actually have any > >pre-1972 timestamps (in documents, databases, etc.) for which precise > >sub-second interpretation is necessary? > > I guess only Dennis, Ken or Brian could be affected, and I doubt they > bothered to set their clocks even to second precision. > > http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html Which says that Unix time settled on its current rate and epoch in 1973, so there won't be timestamps from before then. I'd expect astronomers to have some. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From sla at ucolick.org Mon Feb 16 19:38:03 2009 From: sla at ucolick.org (Steve Allen) Date: Mon, 16 Feb 2009 16:38:03 -0800 Subject: [LEAPSECS] Pre-1972 UTC In-Reply-To: References: <5787.1234656918@critter.freebsd.dk> Message-ID: <20090217003803.GA19910@ucolick.org> On Mon 2009-02-16T23:22:49 +0000, Tony Finch hath writ: > > http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html > > Which says that Unix time settled on its current rate and epoch in 1973, > so there won't be timestamps from before then. And that means that the POSIX epoch encompasses almost as much proleptic fantasy as the use of UTC (or GMT) for the 1601 epoch. The observatory at Greenwich wasn't commissioned for another 75 years, not until after 3 coronations and a civil war. I barely want to mention Microsoft's use of the 0001 epoch in .NET > I'd expect astronomers to have some. Yes, thousands of them. The ones with that sort of precision are almost every observation made by the transit circles -- many of those being the ones which Newcomb used to create his Tables of the planets and expression for UT -- many of which are still the inputs Standish selected for the JPL planetary ephemerides. Those stand together with the timed occultations used by Morrison and Stephenson and collaborators to calibrate the nonuniformity of UT. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From dot at dotat.at Tue Feb 17 07:27:12 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 17 Feb 2009 12:27:12 +0000 Subject: [LEAPSECS] Pre-1972 UTC In-Reply-To: <20090217003803.GA19910@ucolick.org> References: <5787.1234656918@critter.freebsd.dk> <20090217003803.GA19910@ucolick.org> Message-ID: On Mon, 16 Feb 2009, Steve Allen wrote: > > And that means that the POSIX epoch encompasses almost as much > proleptic fantasy as the use of UTC (or GMT) for the 1601 epoch. The > observatory at Greenwich wasn't commissioned for another 75 years, not > until after 3 coronations and a civil war. I barely want to mention > Microsoft's use of the 0001 epoch in .NET And the Airey transit circle didn't exist until 1850. The observatory at Kew provided official time for London from about 1770. I don't know when Greenwich took over that job. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From ashtongj at comcast.net Tue Feb 17 15:08:18 2009 From: ashtongj at comcast.net (Gerard Ashton) Date: Tue, 17 Feb 2009 15:08:18 -0500 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: Message-ID: Oasis will soon present for public review "eNotarization Markup Language (ENML) Version 1.0" which is a proposed standard to represent a notarized document in XML. It is available in several formats at http://www.oasis-open.org/committees/documents.php?wg_abbrev=legalxml-enotar y One of the requirements of the standard is to label certain portions of the document with an ID that will, in all probability, be globally unique. Several fields are concatenated together to form what the authors hope will be a unique id, and one of the fields is defined as follows (p. 175): Concatenate the "epoch" time at the time this ID value is being generated ; the "epoch" time is the number of seconds elapsed since 00:00:00 Coordinated Universal Time (UTC) January 01, 1970 (not counting leap seconds) Since this is only being used to generate a unique value, the accuracy of the value is not as important as it otherwise might be, but I observe the following issues: 1. Although the present version of the standard only uses the value for uniqueness, standards are often extended, and poor initial definitions inhibit useful extensions. 2. It has all the problems of what UTC means before 1972 that have been discussed in this mailing list, as well as what kind of seconds are intended. 3. Unlike the POSIX standard, it presents no algorithm to convert a contemporary UTC time and date to a field value. 4. "'epoch' time" is a strange phrase in this context. 5. Despite the limited purpose of the value, those interpreting documents that conform to the standard may decide to process the value and treat the time as if it were legally meaningful. I suspect the goals of the authors were to define the field so that A. Is directly available as an object in the authors' preferred programming environment, which I believe is Java Beans, B. If need be, can be interpreted without specialized computer software. Maybe there is a way to generate a random number instead of a time that would serve the same purpose, but defining such a random number generator and interpreting the results without access to the computer that generated it might be a problem. I'm not aware of any time scale that meets all the following requirements: a. Rigorously defined epoch, rigorous definition of whether SI or UT1 second is used. b. Directly available in most programming environments. c. Contains a minimal number of non-alphanumeric characters to facilitate parsing. d. The same time will be represented identically, character-for-character, in all implementations. If such a time scale existed, it would make a good replacement for the definition in the standard. Since postings to a mailing list carry little weight, it would be better if any objections to the proposed standard could be substantiated in an authoritative source. Thoughts? Gerry Ashton From dot at dotat.at Tue Feb 17 15:23:11 2009 From: dot at dotat.at (Tony Finch) Date: Tue, 17 Feb 2009 20:23:11 +0000 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: References: Message-ID: On Tue, 17 Feb 2009, Gerard Ashton wrote: > > Concatenate the "epoch" time at the time this ID value is being > generated ; the "epoch" time is the number of seconds elapsed since > 00:00:00 Coordinated Universal Time (UTC) January 01, > 1970 (not counting leap seconds) > > 2. It has all the problems of what UTC means before 1972 that have been > discussed in this mailing list, as well as what kind of seconds are > intended. You can avoid that by specifying that the timescale can be any variant of UT (UT1 or UTC or POSIX time, etc.) and is accurate to no better than a second. A better solution than a seconds count would be to use an ISO 8601 string. > a. Rigorously defined epoch, rigorous definition of whether SI or UT1 second > is used. Don't bother worrying about what kind of seconds you have, because no commodity computing environments do. > c. Contains a minimal number of non-alphanumeric characters to facilitate > parsing. Punctuation is optional in ISO 8601. > d. The same time will be represented identically, > character-for-character, in all implementations. Use ISO 8601 zulu time. You probably need to specify a strict profile, in the manner of RFC 3339. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From imp at bsdimp.com Tue Feb 17 15:32:12 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue, 17 Feb 2009 13:32:12 -0700 (MST) Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: References: Message-ID: <20090217.133212.-828392962.imp@bsdimp.com> In message: "Gerard Ashton" writes: : Concatenate the "epoch" time at the time this ID value is being : generated ; the "epoch" time is the number of seconds elapsed since : 00:00:00 Coordinated Universal Time (UTC) January 01, I think it would be better to define this in a different way. It should be defined more like: ((year - 1970) * 365 + ((year - 1969) / 4) + day_of_year) * 86400 + hour * 3600 + min * 60 + sec Since that's what they mean. Jan 1 is day 0, Jan 5 is day 4, etc. Warner From phk at phk.freebsd.dk Tue Feb 17 15:39:06 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 17 Feb 2009 20:39:06 +0000 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: Your message of "Tue, 17 Feb 2009 13:32:12 MST." <20090217.133212.-828392962.imp@bsdimp.com> Message-ID: <15833.1234903146@critter.freebsd.dk> In message <20090217.133212.-828392962.imp at bsdimp.com>, "M. Warner Losh" writes : >In message: > "Gerard Ashton" writes: >: Concatenate the "epoch" time at the time this ID value is being >: generated ; the "epoch" time is the number of seconds elapsed since >: 00:00:00 Coordinated Universal Time (UTC) January 01, > >I think it would be better to define this in a different way. It >should be defined more like: > > ((year - 1970) * 365 + ((year - 1969) / 4) + day_of_year) * 86400 + > hour * 3600 + min * 60 + sec It would have been even better to write: An ISO C "time_t" timestamp. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From phk at phk.freebsd.dk Tue Feb 17 15:43:37 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 17 Feb 2009 20:43:37 +0000 Subject: [LEAPSECS] failure notice In-Reply-To: Your message of "17 Feb 2009 20:41:04 GMT." <20090217204114.0BC923F129@phk.freebsd.dk> Message-ID: <15885.1234903417@critter.freebsd.dk> Every time I post to this list I get this bounce back, but it is not clear to me who the list-admin is who can remove this fella ? Poul-Henning In message <20090217204114.0BC923F129 at phk.freebsd.dk>, MAILER-DAEMON at mail.philo nline.com writes: >Hi. This is the qmail-send program at mail.philonline.com. >I'm afraid I wasn't able to deliver your message to the following addresses. >This is a permanent error; I've given up. Sorry it didn't work out. > >: >This account is inactive. > >--- Below this line is a copy of the message. > >Return-Path: >Received: (qmail 16882 invoked by alias); 17 Feb 2009 20:40:49 -0000 >Delivered-To: alias-rsgumban at mail0.mindgate.net >Received: (qmail 16731 invoked from network); 17 Feb 2009 20:40:37 -0000 >Received: from unknown (HELO smtp01.philonline.com) (10.5.0.11) > by core with SMTP; 17 Feb 2009 20:40:37 -0000 >Received: from (140.174.90.13) by smtp01.philonline.com (INTIGRIX AnyMail r1.1) with ESMTP; Wed, 18 Feb 2009 05:00:04 +0800; id [6a61515833.1234903146-critter.freebsd.dk] >Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) > by www11.mindgate.net (8.13.1/8.13.1) with ESMTP id n1HKd5cW016133 > for ; Wed, 18 Feb 2009 04:39:16 +0800 >Received: from six.pairlist.net (localhost [127.0.0.1]) > by six.pairlist.net (Postfix) with ESMTP id 705A26CDF7; > Tue, 17 Feb 2009 15:39:05 -0500 (EST) >X-Original-To: leapsecs at lists6.leapsecond.com >Delivered-To: leapsecs at six.pairlist.net >Received: from elhaz.pair.com (elhaz.pair.com [209.68.1.176]) > by six.pairlist.net (Postfix) with SMTP id 45E746CCFA > for ; > Tue, 17 Feb 2009 15:39:04 -0500 (EST) >Received: (qmail 5615 invoked by uid 3244); 17 Feb 2009 20:39:04 -0000 >Delivered-To: tvb-leapsecond:com-leapsecs at leapsecond.com >Received: (qmail 5612 invoked from network); 17 Feb 2009 20:39:04 -0000 >Received: from mailwash30.pair.com (66.39.2.30) > by elhaz.pair.com with SMTP; 17 Feb 2009 20:39:04 -0000 >Received: from localhost (localhost [127.0.0.1]) > by mailwash30.pair.com (Postfix) with SMTP id 092BB13084B > for ; Tue, 17 Feb 2009 15:39:04 -0500 (EST) >Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) > by mailwash30.pair.com (Postfix) with ESMTP id DDF2613084A > for ; Tue, 17 Feb 2009 15:39:03 -0500 (EST) >Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) > by phk.freebsd.dk (Postfix) with ESMTP id 4B5193F129; > Tue, 17 Feb 2009 20:39:03 +0000 (UTC) >Received: from critter.freebsd.dk (localhost [127.0.0.1]) > by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n1HKd6vP015834; > Tue, 17 Feb 2009 20:39:06 GMT (envelope-from phk at critter.freebsd.dk) >To: Leap Second Discussion List >From: Poul-Henning Kamp >In-Reply-To: Your message of "Tue, 17 Feb 2009 13:32:12 MST." > <20090217.133212.-828392962.imp at bsdimp.com> >Date: Tue, 17 Feb 2009 20:39:06 +0000 >Message-ID: <15833.1234903146 at critter.freebsd.dk> >Subject: Re: [LEAPSECS] A new use for Pre-1972 UTC >X-BeenThere: leapsecs at leapsecond.com >X-Mailman-Version: 2.1.9 >Precedence: list >Reply-To: Leap Second Discussion List >List-Id: Leap Second Discussion List >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >MIME-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Content-Transfer-Encoding: 7bit >Sender: leapsecs-bounces at leapsecond.com >Errors-To: leapsecs-bounces at leapsecond.com >X-Envelope-Sender: leapsecs-bounces at leapsecond.com >X-Envelope-Recipient: rsgumban at mail0.mindgate.net >X-Intigrix-Mail-ID: 6a61515833.1234903146-critter.freebsd.dk > >In message <20090217.133212.-828392962.imp at bsdimp.com>, "M. Warner Losh" writes >: >>In message: >> "Gerard Ashton" writes: >>: Concatenate the "epoch" time at the time this ID value is being >>: generated ; the "epoch" time is the number of seconds elapsed since >>: 00:00:00 Coordinated Universal Time (UTC) January 01, >> >>I think it would be better to define this in a different way. It >>should be defined more like: >> >> ((year - 1970) * 365 + ((year - 1969) / 4) + day_of_year) * 86400 + >> hour * 3600 + min * 60 + sec > >It would have been even better to write: > > An ISO C "time_t" timestamp. > >Poul-Henning > >-- >Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >phk at 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 at leapsecond.com >http://six.pairlist.net/mailman/listinfo/leapsecs > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From seaman at noao.edu Tue Feb 17 15:47:45 2009 From: seaman at noao.edu (Rob Seaman) Date: Tue, 17 Feb 2009 13:47:45 -0700 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <15833.1234903146@critter.freebsd.dk> References: <15833.1234903146@critter.freebsd.dk> Message-ID: The URL to the OASIS document didn't work for me, so it's hard to evaluate the reasoning behind the choice of format here. What exactly is the use case they are trying to satisfy? That said, I'm with Tony. This seems like what ISO 8601 was designed for. If not ISO 8601, how about Julian day number to 5 or 6 decimal places? Why do they need a count of elapsed seconds? Requirements are good. Challenging them aggressively is better. Rob --- On Feb 17, 2009, at 1:39 PM, Poul-Henning Kamp wrote: > In message <20090217.133212.-828392962.imp at bsdimp.com>, "M. Warner > Losh" writes > : >> In message: >> "Gerard Ashton" writes: >> : Concatenate the "epoch" time at the time this ID value is being >> : generated ; the "epoch" time is the number of seconds elapsed >> since >> : 00:00:00 Coordinated Universal Time (UTC) January 01, >> >> I think it would be better to define this in a different way. It >> should be defined more like: >> >> ((year - 1970) * 365 + ((year - 1969) / 4) + day_of_year) * >> 86400 + >> hour * 3600 + min * 60 + sec > > It would have been even better to write: > > An ISO C "time_t" timestamp. > > Poul-Henning From phk at phk.freebsd.dk Tue Feb 17 15:53:43 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 17 Feb 2009 20:53:43 +0000 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: Your message of "Tue, 17 Feb 2009 13:47:45 MST." Message-ID: <15947.1234904023@critter.freebsd.dk> In message , Rob Seaman writes: >What exactly >is the use case they are trying to satisfy? That said, I'm with >Tony. This seems like what ISO 8601 was designed for. They are trying to make a unique pseudo-random number, not a timestamp. To decrease the probability of two persons or programs choosing the same number, then include a timestamp in it. time_t values are readily available in all POSIX filesystems, so they use that. This is a variant of the UUID madness that somebody came up with because they didn't want to run a registry or use the existing well-structured process (ISO OID's) and though that the eventual collisions "probably doesn't matter much". Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From clive at davros.org Tue Feb 17 16:02:05 2009 From: clive at davros.org (Clive D.W. Feather) Date: Tue, 17 Feb 2009 21:02:05 +0000 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <15833.1234903146@critter.freebsd.dk> References: <20090217.133212.-828392962.imp@bsdimp.com> <15833.1234903146@critter.freebsd.dk> Message-ID: <20090217210205.GB91747@davros.org> Poul-Henning Kamp said: > It would have been even better to write: > > An ISO C "time_t" timestamp. ISO C doesn't define the type, format, or meaning of time_t - it can even be floating point or (IIRC) a structure. -- Clive D.W. Feather | If you lie to the compiler, clive at davros.org | it will get its revenge. http://www.davros.org | - Henry Spencer From phk at phk.freebsd.dk Tue Feb 17 16:03:08 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 17 Feb 2009 21:03:08 +0000 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: Your message of "Tue, 17 Feb 2009 21:02:05 GMT." <20090217210205.GB91747@davros.org> Message-ID: <16062.1234904588@critter.freebsd.dk> In message <20090217210205.GB91747 at davros.org>, "Clive D.W. Feather" writes: >Poul-Henning Kamp said: >> It would have been even better to write: >> >> An ISO C "time_t" timestamp. > >ISO C doesn't define the type, format, or meaning of time_t - it can even >be floating point or (IIRC) a structure. No, it must be an arithmetic type. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From clive at davros.org Tue Feb 17 16:04:45 2009 From: clive at davros.org (Clive D.W. Feather) Date: Tue, 17 Feb 2009 21:04:45 +0000 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <20090217.133212.-828392962.imp@bsdimp.com> References: <20090217.133212.-828392962.imp@bsdimp.com> Message-ID: <20090217210445.GC91747@davros.org> M. Warner Losh said: > I think it would be better to define this in a different way. It > should be defined more like: > > ((year - 1970) * 365 + ((year - 1969) / 4) + day_of_year) * 86400 + > hour * 3600 + min * 60 + sec > > Since that's what they mean. Jan 1 is day 0, Jan 5 is day 4, etc. Since this use case doesn't care if there are gaps in the scale, I would make it: (((((year-1970) * 12 + month) * 31 + day) * 24 + hour) * 60 + min) * 60 + sec or (((((year-1970) * 16 + month) * 32 + day) * 32 + hour) * 64 + min) * 64 + sec or some such. -- Clive D.W. Feather | If you lie to the compiler, clive at davros.org | it will get its revenge. http://www.davros.org | - Henry Spencer From clive at davros.org Tue Feb 17 16:05:18 2009 From: clive at davros.org (Clive D.W. Feather) Date: Tue, 17 Feb 2009 21:05:18 +0000 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <16062.1234904588@critter.freebsd.dk> References: <20090217210205.GB91747@davros.org> <16062.1234904588@critter.freebsd.dk> Message-ID: <20090217210518.GD91747@davros.org> Poul-Henning Kamp said: >> ISO C doesn't define the type, format, or meaning of time_t - it can even >> be floating point or (IIRC) a structure. > No, it must be an arithmetic type. Okay (I didn't have the standard in front of me). That still allows floating point. -- Clive D.W. Feather | If you lie to the compiler, clive at davros.org | it will get its revenge. http://www.davros.org | - Henry Spencer From phk at phk.freebsd.dk Tue Feb 17 16:06:58 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 17 Feb 2009 21:06:58 +0000 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: Your message of "Tue, 17 Feb 2009 21:05:18 GMT." <20090217210518.GD91747@davros.org> Message-ID: <16088.1234904818@critter.freebsd.dk> In message <20090217210518.GD91747 at davros.org>, "Clive D.W. Feather" writes: >Poul-Henning Kamp said: >>> ISO C doesn't define the type, format, or meaning of time_t - it can even >>> be floating point or (IIRC) a structure. >> No, it must be an arithmetic type. > >Okay (I didn't have the standard in front of me). That still allows >floating point. And that wouldn't matter, the objective is to make a random number. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From clive at davros.org Tue Feb 17 16:16:36 2009 From: clive at davros.org (Clive D.W. Feather) Date: Tue, 17 Feb 2009 21:16:36 +0000 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <16088.1234904818@critter.freebsd.dk> References: <20090217210518.GD91747@davros.org> <16088.1234904818@critter.freebsd.dk> Message-ID: <20090217211636.GF91747@davros.org> Poul-Henning Kamp said: >>>> ISO C doesn't define the type, format, or meaning of time_t - it can even >>>> be floating point or (IIRC) a structure. >> Okay (I didn't have the standard in front of me). That still allows >> floating point. > > And that wouldn't matter, the objective is to make a random number. But what would matter is that time_t on my machine and yours might be completely different. On yours it might be a floating point version of the POSIX value, while on mine it might be Julian date, using fractions to represent the time of day. -- Clive D.W. Feather | If you lie to the compiler, clive at davros.org | it will get its revenge. http://www.davros.org | - Henry Spencer From sla at ucolick.org Tue Feb 17 16:17:20 2009 From: sla at ucolick.org (Steve Allen) Date: Tue, 17 Feb 2009 13:17:20 -0800 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <15947.1234904023@critter.freebsd.dk> References: <15947.1234904023@critter.freebsd.dk> Message-ID: <20090217211720.GB28954@ucolick.org> On Tue 2009-02-17T20:53:43 +0000, Poul-Henning Kamp hath writ: > This is a variant of the UUID madness that somebody came up with > because they didn't want to run a registry or use the existing > well-structured process (ISO OID's) and though that the eventual > collisions "probably doesn't matter much". And the upshot is software that believes that the system clock is always right. Or, more weakly, saying the system clock must be monotonic -- but that is basically saying that if the clock ever gets fast then it must stay fast. So if the clock gets wrong it must stay wrong, or else at least it must get right in a fashion that is consistent with that software's notion -- despite any side effects that might have on the requirements of other systems that depend on time. The fallacy that "my sense of time is always right" is what led to a different kind of collision, the grounding of ships off Scilly in 1707, and the development of marine chronometers. The navigators who used marine chonometers knew perfectly well that those chronometers did not keep the "right" time as measured by clocks on land being reset by telescopes. Instead they knew that if their chronmeters were treated well they kept uniform time, and those navigators knew that getting the "right" time meant keeping a log of the difference between the "right" time of the clocks on land and their chronometer. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From seaman at noao.edu Tue Feb 17 16:27:31 2009 From: seaman at noao.edu (Rob Seaman) Date: Tue, 17 Feb 2009 14:27:31 -0700 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <15947.1234904023@critter.freebsd.dk> References: <15947.1234904023@critter.freebsd.dk> Message-ID: Poul-Henning Kamp wrote: > They are trying to make a unique pseudo-random number, not a > timestamp. Well, it's both. So it turns out that I'm responsible for capturing data from a couple of dozen cameras on eleven telescopes on three mountaintops in two hemispheres. Without belaboring all the astronomy stuff that has entertained us, lo these many years, there are many identifiers and timestamps (and checksums and ...) attached to each image file. One thing we decided to add many years ago was a unique ID from each camera. The format is some variation of: ... The precise formatting of the ISO timestamp varies depending on who implemented the particular software for that camera, but all are standard variations. The serial number is usually omitted, but it permits distinguishing images from cameras that can take very quick (or simultaneous) exposures. I'm guessing that they want to do something similar here. > To decrease the probability of two persons or programs choosing the > same number, then include a timestamp in it. > > time_t values are readily available in all POSIX filesystems, > so they use that. ISO is readily available, too: $ date -u +'%Y%m%dT%H%M%S' 20090217T211132 > This is a variant of the UUID madness that somebody came up with > because they didn't want to run a registry or use the existing > well-structured process (ISO OID's) and though that the eventual > collisions "probably doesn't matter much". Yeah - it all comes down to use cases and whether the requirements address them properly. Creating an ID that is guaranteed unique is not a trivial task, especially if (as one suspects is true here) a central server is out of the question. For example, I control the context for those eleven telescopes. If eleven different organizations were assigning IDs, then you have to somehow guarantee that they don't choose the same telescope or camera names - because it is a frequent occurrence that the timestamps will coincide (no matter what format is chosen). Hmmm. I'll have to run the statistics on that - it's the Birthday Problem. A classroom of more than 23 students has a better than even chance of some pair of students sharing a birthday. Similarly, eleven telescopes producing a couple of hundred images each per night have a high probability of coincidence. Rob From ashtongj at comcast.net Tue Feb 17 16:28:34 2009 From: ashtongj at comcast.net (Gerard Ashton) Date: Tue, 17 Feb 2009 16:28:34 -0500 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: Message-ID: <515DD95B80414F2686A3191359929E29@grendel> Perhaps a link to the PDF version will work better: http://www.oasis-open.org/committees/download.php/31222/ENML-1.0-Specificati on.pdf -----Original Message----- From: leapsecs-bounces at leapsecond.com [mailto:leapsecs-bounces at leapsecond.com] On Behalf Of Rob Seaman Sent: Tuesday, February 17, 2009 3:48 PM To: Leap Second Discussion List Subject: Re: [LEAPSECS] A new use for Pre-1972 UTC The URL to the OASIS document didn't work for me ... From seaman at noao.edu Tue Feb 17 16:44:26 2009 From: seaman at noao.edu (Rob Seaman) Date: Tue, 17 Feb 2009 14:44:26 -0700 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <515DD95B80414F2686A3191359929E29@grendel> References: <515DD95B80414F2686A3191359929E29@grendel> Message-ID: <7CD11BAC-5109-4FF6-9F81-61623FCC4228@noao.edu> Thanks, that's better. Ok, so the format is like: ----- The hash is over the named element (minus the ID itself). The hash itself is what does all the heavy lifting. The rest of it is really for human consumption. A particular notary will be decipherable. Expressing the epoch as ISO 8601 should be, too. That would permit easy grepping (for instance) for documents signed by a particular individual (or agent of same) on a particular date. 5000+ consecutive nights of tracking data issues resulting from several million documents (images) let me unequivocally assert that you want ISO 8601 here. Don't keep the date of signing obscure from the users. Rob --- On Feb 17, 2009, at 2:28 PM, Gerard Ashton wrote: > Perhaps a link to the PDF version will work better: > > http://www.oasis-open.org/committees/download.php/31222/ENML-1.0-Specificati > on.pdf > > -----Original Message----- > From: leapsecs-bounces at leapsecond.com > [mailto:leapsecs-bounces at leapsecond.com] On Behalf Of Rob Seaman > Sent: Tuesday, February 17, 2009 3:48 PM > To: Leap Second Discussion List > Subject: Re: [LEAPSECS] A new use for Pre-1972 UTC > > > The URL to the OASIS document didn't work for me ... > > _______________________________________________ > LEAPSECS mailing list > LEAPSECS at leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs From ashtongj at comcast.net Tue Feb 17 16:45:15 2009 From: ashtongj at comcast.net (Gerard Ashton) Date: Tue, 17 Feb 2009 16:45:15 -0500 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: Message-ID: <15BD1B4EDD544644ADA4E8F30825F688@grendel> Rob Seaman wrote in part: Creating an ID that is guaranteed unique is not a trivial task, especially if (as one suspects is true here) a central server is out of the question. I'm not familiar with the details of OID, but in general, it would be desireable to have the option to perform digital notarizations in areas that are not served by the Internet, or on a computer that is not connected to any network whatsoever (except through "sneakernet"). Gerry Ashton From gwinn at raytheon.com Tue Feb 17 16:54:12 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Tue, 17 Feb 2009 16:54:12 -0500 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <20090217211720.GB28954@ucolick.org> Message-ID: leapsecs-bounces at leapsecond.com wrote on 02/17/2009 04:17:20 PM: > On Tue 2009-02-17T20:53:43 +0000, Poul-Henning Kamp hath writ: > > This is a variant of the UUID madness that somebody came up with > > because they didn't want to run a registry or use the existing > > well-structured process (ISO OID's) and though that the eventual > > collisions "probably doesn't matter much". > > And the upshot is software that believes that the system clock is > always right. Or, more weakly, saying the system clock must be > monotonic -- but that is basically saying that if the clock ever gets > fast then it must stay fast. So if the clock gets wrong it must stay > wrong, or else at least it must get right in a fashion that is > consistent with that software's notion -- despite any side effects > that might have on the requirements of other systems that depend on > time. No, monotonic does not imply that. One can speed up and slow down, so long as one does so gently enough. This is exactly what NTP does in normal operation. > The fallacy that "my sense of time is always right" is what led to a > different kind of collision, the grounding of ships off Scilly in > 1707, and the development of marine chronometers. The navigators who > used marine chonometers knew perfectly well that those chronometers > did not keep the "right" time as measured by clocks on land being > reset by telescopes. Instead they knew that if their chronmeters were > treated well they kept uniform time, and those navigators knew that > getting the "right" time meant keeping a log of the difference between > the "right" time of the clocks on land and their chronometer. They used the best cronometers then available. Harrison's first attempt at a chronometer was in 1730, and success came many years later, in 1760 or so. Joe From seaman at noao.edu Tue Feb 17 16:56:30 2009 From: seaman at noao.edu (Rob Seaman) Date: Tue, 17 Feb 2009 14:56:30 -0700 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <15BD1B4EDD544644ADA4E8F30825F688@grendel> References: <15BD1B4EDD544644ADA4E8F30825F688@grendel> Message-ID: <80784569-323E-4016-8EAF-C11E3531EF1A@noao.edu> They avoid the issue by piggybacking on the current model. A Notary Public has a commission assigned by some locale. I'll take their word for it that this breaks down by country/state. (One could wish they called this province or locale or some such.) The SHA disambiguates the case of a particular Notary resetting their clock to sign a later modified copy of a document. Nothing stops the epoch from simply being incorrect. That is an issue for a court to resolve should it become pertinent. Similarly if someone masquerades as a notary. There would otherwise have to be some sort of certificate exchange to extend the trust model. Rob --- On Feb 17, 2009, at 2:45 PM, Gerard Ashton wrote: > Rob Seaman wrote in part: > Creating an ID that is guaranteed unique is not a trivial task, > especially if (as one suspects is true here) a central server is out > of the question. > > I'm not familiar with the details of OID, but in general, it would be > desireable to have the option to perform digital notarizations in > areas > that are not served by the Internet, or on a computer that is not > connected > to any network whatsoever (except through "sneakernet"). > > Gerry Ashton > > _______________________________________________ > LEAPSECS mailing list > LEAPSECS at leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs From phk at phk.freebsd.dk Tue Feb 17 17:30:52 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 17 Feb 2009 22:30:52 +0000 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: Your message of "Tue, 17 Feb 2009 21:16:36 GMT." <20090217211636.GF91747@davros.org> Message-ID: <16593.1234909852@critter.freebsd.dk> In message <20090217211636.GF91747 at davros.org>, "Clive D.W. Feather" writes: >Poul-Henning Kamp said: >>>>> ISO C doesn't define the type, format, or meaning of time_t - it can even >>>>> be floating point or (IIRC) a structure. > >>> Okay (I didn't have the standard in front of me). That still allows >>> floating point. >> >> And that wouldn't matter, the objective is to make a random number. > >But what would matter is that time_t on my machine and yours might be >completely different. And that would be perfect, because then there is even less chance of you creating a random identifier that is identical to mine. Remember, this is a write-only timestamp, its only purpose is to provide time-changing bits. What those bits mean does not matter. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at 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. From seaman at noao.edu Tue Feb 17 17:50:39 2009 From: seaman at noao.edu (Rob Seaman) Date: Tue, 17 Feb 2009 15:50:39 -0700 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <16593.1234909852@critter.freebsd.dk> References: <16593.1234909852@critter.freebsd.dk> Message-ID: <42CB9C62-D2FB-4907-8FA3-02D45DE8AC61@noao.edu> Poul-Henning Kamp wrote: > And that would be perfect, because then there is even less chance of > you creating a random identifier that is identical to mine. > > Remember, this is a write-only timestamp, its only purpose is to > provide time-changing bits. What those bits mean does not matter. There is already zero chance since the timestamp is attached to SHA-256. If there is no requirement to provide a human readable timestamp, they should omit it. Rather, as with the fields identifying the notary and document name, the timestamp is fodder for list handling. It will allow sorting the list, and should allow grabbing specific dates from the list if they don't obscure it too much. The key issue with dates (as opposed to epochs) is whether local or UT is more pertinent. If these were human notaries, a strong argument could be made for local time since resolution at the level of a particular calendar date will often be required. Actually, there is a failure of the current scheme in the document. A notary is per country/state pair. But about a third of the U.S. states and presumably many provinces in other countries are split by timezones. A particular notary can therefore be expected to roam over more than one timezone. Even if they demand a UTC timestamp, there is no likelihood that such an itinerant authority will accommodate this correctly. For instance, imagine a Notary working out of the back of a Winnebago up and down an E/W highway. Are they likely to reset the timezone appropriately on their laptop? Rob From ashtongj at comcast.net Tue Feb 17 18:35:09 2009 From: ashtongj at comcast.net (Gerard Ashton) Date: Tue, 17 Feb 2009 18:35:09 -0500 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <42CB9C62-D2FB-4907-8FA3-02D45DE8AC61@noao.edu> Message-ID: <3E0E29A844604811B02084FBBA160F66@grendel> Rob Seaman wrote in part: Actually, there is a failure of the current scheme in the document. A notary is per country/state pair. But about a third of the U.S. states and presumably many provinces in other countries are split by timezones .... Notaries are usually allowed to notarize anywhere in a state, no matter which county they were commissioned in. (I deliberately didn't say "county or parish" since I think Louisiana is one of the exceptions.) The UT time on the notary's computer will probably be correct, since once the time zone offset of the computer is combined with the local time of the computer, the result will probably be correct. The notary will be indicating the date and time elsewhere in the document; the means for capturing that information is not specified. Gerry Ashton From seaman at noao.edu Tue Feb 17 18:40:32 2009 From: seaman at noao.edu (Rob Seaman) Date: Tue, 17 Feb 2009 16:40:32 -0700 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: <3E0E29A844604811B02084FBBA160F66@grendel> References: <3E0E29A844604811B02084FBBA160F66@grendel> Message-ID: <14F2E955-6E41-4E00-BFE9-DEE9DAA05673@noao.edu> Gerard Ashton wrote: > (I deliberately didn't say "county or parish" since I think > Louisiana is one of the exceptions.) And of course, four of the states are actually commonwealths :-) Rob From dan at tobias.name Tue Feb 17 21:42:17 2009 From: dan at tobias.name (Daniel R. Tobias) Date: Tue, 17 Feb 2009 21:42:17 -0500 Subject: [LEAPSECS] A new use for Pre-1972 UTC In-Reply-To: References: <15947.1234904023@critter.freebsd.dk>, Message-ID: <499B2F39.30990.E482862@dan.tobias.name> On 17 Feb 2009 at 14:27, Rob Seaman wrote: > Creating an ID that is guaranteed unique is not a trivial task, > especially if (as one suspects is true here) a central server is out > of the question. If the ID includes as one of its elements a fully qualified domain name, and the owner/operator of that domain (as of the date and time indicated by a timestamp that's another element of the ID) makes sure to prevent duplicate IDs within their domain, then this would be achieved. The domain could include an arbitrary number of levels of subdomains or hostnames, letting each distinct machine which is generating IDs have a unique ID namespace, reducing the problem to making sure each ID generated by a particular machine is unique. -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/ From dot at dotat.at Wed Feb 18 09:56:10 2009 From: dot at dotat.at (Tony Finch) Date: Wed, 18 Feb 2009 14:56:10 +0000 Subject: [LEAPSECS] Marine chronometers, was Re: A new use for Pre-1972 UTC In-Reply-To: References: Message-ID: On Tue, 17 Feb 2009, Joseph M Gwinn wrote: > > > The navigators who used marine chonometers knew perfectly well that > > those chronometers did not keep the "right" time as measured by clocks > > on land being reset by telescopes. Instead they knew that if their > > chronmeters were treated well they kept uniform time, and those > > navigators knew that getting the "right" time meant keeping a log of > > the difference between the "right" time of the clocks on land and > > their chronometer. > > They used the best cronometers then available. Harrison's first attempt > at a chronometer was in 1730, and success came many years later, in 1760 > or so. Steve is right. The key difference between H4 and Harrison's previous clocks is that he gave up trying to make a clock that keeps correct tims and instead designed a clock that kept uniform time, which he could calibrate before a journey. This is often not well explained in the potted histories. Tony. -- f.anthony.n.finch http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. From gwinn at raytheon.com Wed Feb 18 15:44:19 2009 From: gwinn at raytheon.com (Joseph M Gwinn) Date: Wed, 18 Feb 2009 15:44:19 -0500 Subject: [LEAPSECS] Marine chronometers, was Re: A new use for Pre-1972 UTC In-Reply-To: Message-ID: leapsecs-bounces at leapsecond.com wrote on 02/18/2009 09:56:10 AM: > On Tue, 17 Feb 2009, Joseph M Gwinn wrote: > > > > > The navigators who used marine chonometers knew perfectly well that > > > those chronometers did not keep the "right" time as measured by clocks > > > on land being reset by telescopes. Instead they knew that if their > > > chronmeters were treated well they kept uniform time, and those > > > navigators knew that getting the "right" time meant keeping a log of > > > the difference between the "right" time of the clocks on land and > > > their chronometer. > > > > They used the best cronometers then available. Harrison's first attempt > > at a chronometer was in 1730, and success came many years later, in 1760 > > or so. > > Steve is right. The key difference between H4 and Harrison's previous > clocks is that he gave up trying to make a clock that keeps correct time > and instead designed a clock that kept uniform time, which he could > calibrate before a journey. This is often not well explained inthe potted > histories. I didn't trim enough when I quoted. I was reacting to the complaint about navigation problems in 1707. I think you're right about the history of Harrrison's clocks. It wasn't until 1730 that Harrison achieved sufficient accuracy. Joe