From samp5087 at gmail.com  Wed Aug 20 10:22:47 2014
From: samp5087 at gmail.com (=?UTF-8?Q?Preben_N=C3=B8rager?=)
Date: Wed, 20 Aug 2014 16:22:47 +0200
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
Message-ID: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>

In the discussion about whether or not to drop the leap second, I think it
is not a question about solar time or not solar time. It is in other words
not a question about either solar time or atomic time.



If we drop the leap second it will be in favour of another timescale, which
uses only atomic clocks to tell the time, but the time in that other
timescale will still be based upon a kind of solar time.



About a hundred years ago it was decided, that the mean solar year, and not
the mean solar day, should be the unit of international time.



In 1960 the second was defined as 1/31556925,9747 of the mean solar year,
and in 1967 the second was redefined [equally in length to the previously
defined second] as the duration of 9192632770 periods of radiation.



When the second was defined in 1960 it was defined as a fraction of the
so-called tropical year. That was a mistake of wording. The tropical year
is a measurement of the solar longitude on the ecliptic, but the
international definition of the second is not based upon measurement of the
solar longitude on the ecliptic.



The definition of the second is based upon Newcomb's theory of the solar
system, and in that theory it is the barycenter of the solar system, and
not the center of the sun, which defines the length of the solar year.



The length of the solar year, according to Newcomb?s theory, is the time
for the longitude of the barycenter of the solar system to increase 360
decrees.



The solar year, thus defined, can be measured either for one year, or for
an average of years.


But the 1960 and the 1967 definition of the second can also be used as an
international definition of the mean solar year.


I think we should drop the leap second, and continue UTC without leap
seconds as TI [International Time], so that 1 mean solar year is the
duration of 290091231835491000 [31556925,9747x9192632770] periods of
radiation in the caesium atom.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/b91fa77c/attachment.html>

From keithw at mit.edu  Wed Aug 20 10:43:18 2014
From: keithw at mit.edu (Keith Winstein)
Date: Wed, 20 Aug 2014 09:43:18 -0500
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
Message-ID: <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>

To be a pedant [but if you can't be one on the leapsecs mailing
list...], the SI second is *9192631770* periods of the radiation etc.
Your figure is high by 1000.

On Wed, Aug 20, 2014 at 9:22 AM, Preben N?rager <samp5087 at gmail.com> wrote:
>
> In the discussion about whether or not to drop the leap second, I think it
> is not a question about solar time or not solar time. It is in other words
> not a question about either solar time or atomic time.
>
>
>
> If we drop the leap second it will be in favour of another timescale, which
> uses only atomic clocks to tell the time, but the time in that other
> timescale will still be based upon a kind of solar time.
>
>
>
> About a hundred years ago it was decided, that the mean solar year, and not
> the mean solar day, should be the unit of international time.
>
>
>
> In 1960 the second was defined as 1/31556925,9747 of the mean solar year,
> and in 1967 the second was redefined [equally in length to the previously
> defined second] as the duration of 9192632770 periods of radiation.
>
>
>
> When the second was defined in 1960 it was defined as a fraction of the
> so-called tropical year. That was a mistake of wording. The tropical year is
> a measurement of the solar longitude on the ecliptic, but the international
> definition of the second is not based upon measurement of the solar
> longitude on the ecliptic.
>
>
>
> The definition of the second is based upon Newcomb's theory of the solar
> system, and in that theory it is the barycenter of the solar system, and not
> the center of the sun, which defines the length of the solar year.
>
>
>
> The length of the solar year, according to Newcomb?s theory, is the time for
> the longitude of the barycenter of the solar system to increase 360 decrees.
>
>
>
> The solar year, thus defined, can be measured either for one year, or for an
> average of years.
>
>
> But the 1960 and the 1967 definition of the second can also be used as an
> international definition of the mean solar year.
>
>
>
> I think we should drop the leap second, and continue UTC without leap
> seconds as TI [International Time], so that 1 mean solar year is the
> duration of 290091231835491000 [31556925,9747x9192632770] periods of
> radiation in the caesium atom.
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
>

From samp5087 at gmail.com  Wed Aug 20 11:23:26 2014
From: samp5087 at gmail.com (=?UTF-8?Q?Preben_N=C3=B8rager?=)
Date: Wed, 20 Aug 2014 17:23:26 +0200
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
Message-ID: <CABM=KgYyvndORJ=LB9yVt-hJ_e_W4hRwhqShy-UpW_fZRof9QA@mail.gmail.com>

Thank you Keith, my stupid mistake.
Den 20/08/2014 16.44 skrev "Keith Winstein" <keithw at mit.edu>:

> To be a pedant [but if you can't be one on the leapsecs mailing
> list...], the SI second is *9192631770* periods of the radiation etc.
> Your figure is high by 1000.
>
> On Wed, Aug 20, 2014 at 9:22 AM, Preben N?rager <samp5087 at gmail.com>
> wrote:
> >
> > In the discussion about whether or not to drop the leap second, I think
> it
> > is not a question about solar time or not solar time. It is in other
> words
> > not a question about either solar time or atomic time.
> >
> >
> >
> > If we drop the leap second it will be in favour of another timescale,
> which
> > uses only atomic clocks to tell the time, but the time in that other
> > timescale will still be based upon a kind of solar time.
> >
> >
> >
> > About a hundred years ago it was decided, that the mean solar year, and
> not
> > the mean solar day, should be the unit of international time.
> >
> >
> >
> > In 1960 the second was defined as 1/31556925,9747 of the mean solar
> year,
> > and in 1967 the second was redefined [equally in length to the previously
> > defined second] as the duration of 9192632770 periods of radiation.
> >
> >
> >
> > When the second was defined in 1960 it was defined as a fraction of the
> > so-called tropical year. That was a mistake of wording. The tropical
> year is
> > a measurement of the solar longitude on the ecliptic, but the
> international
> > definition of the second is not based upon measurement of the solar
> > longitude on the ecliptic.
> >
> >
> >
> > The definition of the second is based upon Newcomb's theory of the solar
> > system, and in that theory it is the barycenter of the solar system, and
> not
> > the center of the sun, which defines the length of the solar year.
> >
> >
> >
> > The length of the solar year, according to Newcomb?s theory, is the time
> for
> > the longitude of the barycenter of the solar system to increase 360
> decrees.
> >
> >
> >
> > The solar year, thus defined, can be measured either for one year, or
> for an
> > average of years.
> >
> >
> > But the 1960 and the 1967 definition of the second can also be used as an
> > international definition of the mean solar year.
> >
> >
> >
> > I think we should drop the leap second, and continue UTC without leap
> > seconds as TI [International Time], so that 1 mean solar year is the
> > duration of 290091231835491000 [31556925,9747x9192632770] periods of
> > radiation in the caesium atom.
> >
> > _______________________________________________
> > LEAPSECS mailing list
> > LEAPSECS at leapsecond.com
> > http://six.pairlist.net/mailman/listinfo/leapsecs
> >
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/9252e27a/attachment.html>

From samp5087 at gmail.com  Wed Aug 20 15:42:44 2014
From: samp5087 at gmail.com (=?UTF-8?Q?Preben_N=C3=B8rager?=)
Date: Wed, 20 Aug 2014 21:42:44 +0200
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
Message-ID: <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>

I can not edit the numbers in my initial post, but I can do it here, and
with that my proposel still stands: Drop the leap second, and continue UTC
without leap
seconds, so that 1 mean solar year is defined as the
duration of 290091175979732 [31556925,9747x9192631770] periods of
radiation in the caesium atom


2014-08-20 16:43 GMT+02:00 Keith Winstein <keithw at mit.edu>:

> To be a pedant [but if you can't be one on the leapsecs mailing
> list...], the SI second is *9192631770* periods of the radiation etc.
> Your figure is high by 1000.
>
> On Wed, Aug 20, 2014 at 9:22 AM, Preben N?rager <samp5087 at gmail.com>
> wrote:
> >
> > In the discussion about whether or not to drop the leap second, I think
> it
> > is not a question about solar time or not solar time. It is in other
> words
> > not a question about either solar time or atomic time.
> >
> >
> >
> > If we drop the leap second it will be in favour of another timescale,
> which
> > uses only atomic clocks to tell the time, but the time in that other
> > timescale will still be based upon a kind of solar time.
> >
> >
> >
> > About a hundred years ago it was decided, that the mean solar year, and
> not
> > the mean solar day, should be the unit of international time.
> >
> >
> >
> > In 1960 the second was defined as 1/31556925,9747 of the mean solar
> year,
> > and in 1967 the second was redefined [equally in length to the previously
> > defined second] as the duration of 9192632770 periods of radiation.
> >
> >
> >
> > When the second was defined in 1960 it was defined as a fraction of the
> > so-called tropical year. That was a mistake of wording. The tropical
> year is
> > a measurement of the solar longitude on the ecliptic, but the
> international
> > definition of the second is not based upon measurement of the solar
> > longitude on the ecliptic.
> >
> >
> >
> > The definition of the second is based upon Newcomb's theory of the solar
> > system, and in that theory it is the barycenter of the solar system, and
> not
> > the center of the sun, which defines the length of the solar year.
> >
> >
> >
> > The length of the solar year, according to Newcomb?s theory, is the time
> for
> > the longitude of the barycenter of the solar system to increase 360
> decrees.
> >
> >
> >
> > The solar year, thus defined, can be measured either for one year, or
> for an
> > average of years.
> >
> >
> > But the 1960 and the 1967 definition of the second can also be used as an
> > international definition of the mean solar year.
> >
> >
> >
> > I think we should drop the leap second, and continue UTC without leap
> > seconds as TI [International Time], so that 1 mean solar year is the
> > duration of 290091231835491000 [31556925,9747x9192632770] periods of
> > radiation in the caesium atom.
> >
> > _______________________________________________
> > LEAPSECS mailing list
> > LEAPSECS at leapsecond.com
> > http://six.pairlist.net/mailman/listinfo/leapsecs
> >
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/fa559c19/attachment-0001.html>

From samp5087 at gmail.com  Wed Aug 20 16:02:03 2014
From: samp5087 at gmail.com (=?UTF-8?Q?Preben_N=C3=B8rager?=)
Date: Wed, 20 Aug 2014 22:02:03 +0200
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
 <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>
 <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
Message-ID: <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>

OMG its 290091200278565000. With THAT my proposal still stands :-)


2014-08-20 21:48 GMT+02:00 Keith Winstein <keithw at cs.stanford.edu>:

> Check that multiplication... :-)
>
> On Wed, Aug 20, 2014 at 2:42 PM, Preben N?rager <samp5087 at gmail.com>
> wrote:
> > I can not edit the numbers in my initial post, but I can do it here, and
> > with that my proposel still stands: Drop the leap second, and continue
> UTC
> > without leap
> > seconds, so that 1 mean solar year is defined as the
> > duration of 290091175979732 [31556925,9747x9192631770] periods of
> >
> > radiation in the caesium atom
> >
> >
> >
> > 2014-08-20 16:43 GMT+02:00 Keith Winstein <keithw at mit.edu>:
> >
> >> To be a pedant [but if you can't be one on the leapsecs mailing
> >> list...], the SI second is *9192631770* periods of the radiation etc.
> >> Your figure is high by 1000.
> >>
> >> On Wed, Aug 20, 2014 at 9:22 AM, Preben N?rager <samp5087 at gmail.com>
> >> wrote:
> >> >
> >> > In the discussion about whether or not to drop the leap second, I
> think
> >> > it
> >> > is not a question about solar time or not solar time. It is in other
> >> > words
> >> > not a question about either solar time or atomic time.
> >> >
> >> >
> >> >
> >> > If we drop the leap second it will be in favour of another timescale,
> >> > which
> >> > uses only atomic clocks to tell the time, but the time in that other
> >> > timescale will still be based upon a kind of solar time.
> >> >
> >> >
> >> >
> >> > About a hundred years ago it was decided, that the mean solar year,
> and
> >> > not
> >> > the mean solar day, should be the unit of international time.
> >> >
> >> >
> >> >
> >> > In 1960 the second was defined as 1/31556925,9747 of the mean solar
> >> > year,
> >> > and in 1967 the second was redefined [equally in length to the
> >> > previously
> >> > defined second] as the duration of 9192632770 periods of radiation.
> >> >
> >> >
> >> >
> >> > When the second was defined in 1960 it was defined as a fraction of
> the
> >> > so-called tropical year. That was a mistake of wording. The tropical
> >> > year is
> >> > a measurement of the solar longitude on the ecliptic, but the
> >> > international
> >> > definition of the second is not based upon measurement of the solar
> >> > longitude on the ecliptic.
> >> >
> >> >
> >> >
> >> > The definition of the second is based upon Newcomb's theory of the
> solar
> >> > system, and in that theory it is the barycenter of the solar system,
> and
> >> > not
> >> > the center of the sun, which defines the length of the solar year.
> >> >
> >> >
> >> >
> >> > The length of the solar year, according to Newcomb?s theory, is the
> time
> >> > for
> >> > the longitude of the barycenter of the solar system to increase 360
> >> > decrees.
> >> >
> >> >
> >> >
> >> > The solar year, thus defined, can be measured either for one year, or
> >> > for an
> >> > average of years.
> >> >
> >> >
> >> > But the 1960 and the 1967 definition of the second can also be used as
> >> > an
> >> > international definition of the mean solar year.
> >> >
> >> >
> >> >
> >> > I think we should drop the leap second, and continue UTC without leap
> >> > seconds as TI [International Time], so that 1 mean solar year is the
> >> > duration of 290091231835491000 [31556925,9747x9192632770] periods of
> >> > radiation in the caesium atom.
> >> >
> >> > _______________________________________________
> >> > LEAPSECS mailing list
> >> > LEAPSECS at leapsecond.com
> >> > http://six.pairlist.net/mailman/listinfo/leapsecs
> >> >
> >> _______________________________________________
> >> LEAPSECS mailing list
> >> LEAPSECS at leapsecond.com
> >> http://six.pairlist.net/mailman/listinfo/leapsecs
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/2ba62b04/attachment.html>

From brooks at edlmax.com  Wed Aug 20 21:40:51 2014
From: brooks at edlmax.com (Brooks Harris)
Date: Wed, 20 Aug 2014 21:40:51 -0400
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
 <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>
 <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
 <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>
Message-ID: <53F54E23.4020302@edlmax.com>

Since the beginning of civilization society has pursued the goal of 
perfect timekeeping. UTC is one of the great intellectual achievements 
of mankind.

The difficulties with Leap Seconds are rooted in computer standards and 
implementations, not theory. We must strive to advance the state of the 
art, not abandon 4500 years of timekeeping history just because its 
difficult. Ceaser didn't quit. Pope Gregory didn't quit. Harrison didn't 
quit. Newcomb didn't quit.

"Dropping Leap Seconds" is something like burning great libraries.

-Brooks

On 2014-08-20 04:02 PM, Preben N?rager wrote:
> OMG its 290091200278565000. With THAT my proposal still stands :-)
>
>
> 2014-08-20 21:48 GMT+02:00 Keith Winstein <keithw at cs.stanford.edu 
> <mailto:keithw at cs.stanford.edu>>:
>
>     Check that multiplication... :-)
>
>     On Wed, Aug 20, 2014 at 2:42 PM, Preben N?rager
>     <samp5087 at gmail.com <mailto:samp5087 at gmail.com>> wrote:
>     > I can not edit the numbers in my initial post, but I can do it
>     here, and
>     > with that my proposel still stands: Drop the leap second, and
>     continue UTC
>     > without leap
>     > seconds, so that 1 mean solar year is defined as the
>     > duration of 290091175979732 [31556925
>     <tel:%5B31556925>,9747x9192631770] periods of
>     >
>     > radiation in the caesium atom
>     >
>     >
>     >
>     > 2014-08-20 16:43 GMT+02:00 Keith Winstein <keithw at mit.edu
>     <mailto:keithw at mit.edu>>:
>     >
>     >> To be a pedant [but if you can't be one on the leapsecs mailing
>     >> list...], the SI second is *9192631770* periods of the
>     radiation etc.
>     >> Your figure is high by 1000.
>     >>
>     >> On Wed, Aug 20, 2014 at 9:22 AM, Preben N?rager
>     <samp5087 at gmail.com <mailto:samp5087 at gmail.com>>
>     >> wrote:
>     >> >
>     >> > In the discussion about whether or not to drop the leap
>     second, I think
>     >> > it
>     >> > is not a question about solar time or not solar time. It is
>     in other
>     >> > words
>     >> > not a question about either solar time or atomic time.
>     >> >
>     >> >
>     >> >
>     >> > If we drop the leap second it will be in favour of another
>     timescale,
>     >> > which
>     >> > uses only atomic clocks to tell the time, but the time in
>     that other
>     >> > timescale will still be based upon a kind of solar time.
>     >> >
>     >> >
>     >> >
>     >> > About a hundred years ago it was decided, that the mean solar
>     year, and
>     >> > not
>     >> > the mean solar day, should be the unit of international time.
>     >> >
>     >> >
>     >> >
>     >> > In 1960 the second was defined as 1/31556925
>     <tel:31556925>,9747 of the mean solar
>     >> > year,
>     >> > and in 1967 the second was redefined [equally in length to the
>     >> > previously
>     >> > defined second] as the duration of 9192632770 periods of
>     radiation.
>     >> >
>     >> >
>     >> >
>     >> > When the second was defined in 1960 it was defined as a
>     fraction of the
>     >> > so-called tropical year. That was a mistake of wording. The
>     tropical
>     >> > year is
>     >> > a measurement of the solar longitude on the ecliptic, but the
>     >> > international
>     >> > definition of the second is not based upon measurement of the
>     solar
>     >> > longitude on the ecliptic.
>     >> >
>     >> >
>     >> >
>     >> > The definition of the second is based upon Newcomb's theory
>     of the solar
>     >> > system, and in that theory it is the barycenter of the solar
>     system, and
>     >> > not
>     >> > the center of the sun, which defines the length of the solar
>     year.
>     >> >
>     >> >
>     >> >
>     >> > The length of the solar year, according to Newcomb's theory,
>     is the time
>     >> > for
>     >> > the longitude of the barycenter of the solar system to
>     increase 360
>     >> > decrees.
>     >> >
>     >> >
>     >> >
>     >> > The solar year, thus defined, can be measured either for one
>     year, or
>     >> > for an
>     >> > average of years.
>     >> >
>     >> >
>     >> > But the 1960 and the 1967 definition of the second can also
>     be used as
>     >> > an
>     >> > international definition of the mean solar year.
>     >> >
>     >> >
>     >> >
>     >> > I think we should drop the leap second, and continue UTC
>     without leap
>     >> > seconds as TI [International Time], so that 1 mean solar year
>     is the
>     >> > duration of 290091231835491000 [31556925,9747x9192632770]
>     periods of
>     >> > radiation in the caesium atom.
>     >> >
>     >> > _______________________________________________
>     >> > LEAPSECS mailing list
>     >> > LEAPSECS at leapsecond.com <mailto:LEAPSECS at leapsecond.com>
>     >> > http://six.pairlist.net/mailman/listinfo/leapsecs
>     >> >
>     >> _______________________________________________
>     >> LEAPSECS mailing list
>     >> LEAPSECS at leapsecond.com <mailto:LEAPSECS at leapsecond.com>
>     >> http://six.pairlist.net/mailman/listinfo/leapsecs
>     >
>     >
>
>
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/dcd55db4/attachment-0001.html>

From imp at bsdimp.com  Wed Aug 20 22:23:39 2014
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 20 Aug 2014 20:23:39 -0600
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <53F54E23.4020302@edlmax.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
 <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>
 <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
 <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>
 <53F54E23.4020302@edlmax.com>
Message-ID: <87E90E2B-254B-4741-BB86-E2D9BD46EA5A@bsdimp.com>


On Aug 20, 2014, at 7:40 PM, Brooks Harris <brooks at edlmax.com> wrote:

> Since the beginning of civilization society has pursued the goal of perfect timekeeping. UTC is one of the great intellectual achievements of mankind.
> 
> The difficulties with Leap Seconds are rooted in computer standards and implementations, not theory. We must strive to advance the state of the art, not abandon 4500 years of timekeeping history just because its difficult. Ceaser didn't quit. Pope Gregory didn't quit. Harrison didn't quit. Newcomb didn't quit.
> 
> "Dropping Leap Seconds" is something like burning great libraries.

Not sure I buy this hyperbole. Leap seconds suffer from many minor issues that are only going to increase as we get more and more connected. The stubborn refusal for any changes in the current implementation has me thinking of them as less than great libraries, and more as pebbles in my shoes. There are many better ways to implement them, and ?perfect timekeeping? always begs the question of ?perfect for whom.? De we align them with the day or the year? If we pick one over the other, the other gets out of sync.

Warner

> -Brooks
> 
> On 2014-08-20 04:02 PM, Preben N?rager wrote:
>> OMG its 290091200278565000. With THAT my proposal still stands :-)
>> 
>> 
>> 2014-08-20 21:48 GMT+02:00 Keith Winstein <keithw at cs.stanford.edu>:
>> Check that multiplication... :-)
>> 
>> On Wed, Aug 20, 2014 at 2:42 PM, Preben N?rager <samp5087 at gmail.com> wrote:
>> > I can not edit the numbers in my initial post, but I can do it here, and
>> > with that my proposel still stands: Drop the leap second, and continue UTC
>> > without leap
>> > seconds, so that 1 mean solar year is defined as the
>> > duration of 290091175979732 [31556925,9747x9192631770] periods of
>> >
>> > radiation in the caesium atom
>> >
>> >
>> >
>> > 2014-08-20 16:43 GMT+02:00 Keith Winstein <keithw at mit.edu>:
>> >
>> >> To be a pedant [but if you can't be one on the leapsecs mailing
>> >> list...], the SI second is *9192631770* periods of the radiation etc.
>> >> Your figure is high by 1000.
>> >>
>> >> On Wed, Aug 20, 2014 at 9:22 AM, Preben N?rager <samp5087 at gmail.com>
>> >> wrote:
>> >> >
>> >> > In the discussion about whether or not to drop the leap second, I think
>> >> > it
>> >> > is not a question about solar time or not solar time. It is in other
>> >> > words
>> >> > not a question about either solar time or atomic time.
>> >> >
>> >> >
>> >> >
>> >> > If we drop the leap second it will be in favour of another timescale,
>> >> > which
>> >> > uses only atomic clocks to tell the time, but the time in that other
>> >> > timescale will still be based upon a kind of solar time.
>> >> >
>> >> >
>> >> >
>> >> > About a hundred years ago it was decided, that the mean solar year, and
>> >> > not
>> >> > the mean solar day, should be the unit of international time.
>> >> >
>> >> >
>> >> >
>> >> > In 1960 the second was defined as 1/31556925,9747 of the mean solar
>> >> > year,
>> >> > and in 1967 the second was redefined [equally in length to the
>> >> > previously
>> >> > defined second] as the duration of 9192632770 periods of radiation.
>> >> >
>> >> >
>> >> >
>> >> > When the second was defined in 1960 it was defined as a fraction of the
>> >> > so-called tropical year. That was a mistake of wording. The tropical
>> >> > year is
>> >> > a measurement of the solar longitude on the ecliptic, but the
>> >> > international
>> >> > definition of the second is not based upon measurement of the solar
>> >> > longitude on the ecliptic.
>> >> >
>> >> >
>> >> >
>> >> > The definition of the second is based upon Newcomb's theory of the solar
>> >> > system, and in that theory it is the barycenter of the solar system, and
>> >> > not
>> >> > the center of the sun, which defines the length of the solar year.
>> >> >
>> >> >
>> >> >
>> >> > The length of the solar year, according to Newcomb?s theory, is the time
>> >> > for
>> >> > the longitude of the barycenter of the solar system to increase 360
>> >> > decrees.
>> >> >
>> >> >
>> >> >
>> >> > The solar year, thus defined, can be measured either for one year, or
>> >> > for an
>> >> > average of years.
>> >> >
>> >> >
>> >> > But the 1960 and the 1967 definition of the second can also be used as
>> >> > an
>> >> > international definition of the mean solar year.
>> >> >
>> >> >
>> >> >
>> >> > I think we should drop the leap second, and continue UTC without leap
>> >> > seconds as TI [International Time], so that 1 mean solar year is the
>> >> > duration of 290091231835491000 [31556925,9747x9192632770] periods of
>> >> > radiation in the caesium atom.
>> >> >
>> >> > _______________________________________________
>> >> > LEAPSECS mailing list
>> >> > LEAPSECS at leapsecond.com
>> >> > http://six.pairlist.net/mailman/listinfo/leapsecs
>> >> >
>> >> _______________________________________________
>> >> LEAPSECS mailing list
>> >> LEAPSECS at leapsecond.com
>> >> http://six.pairlist.net/mailman/listinfo/leapsecs
>> >
>> >
>> 
>> 
>> 
>> _______________________________________________
>> LEAPSECS mailing list
>> 
>> LEAPSECS at leapsecond.com
>> http://six.pairlist.net/mailman/listinfo/leapsecs
> 
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/fec448e6/attachment.pgp>

From ask at develooper.com  Wed Aug 20 22:16:14 2014
From: ask at develooper.com (=?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?=)
Date: Wed, 20 Aug 2014 19:16:14 -0700
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <mailman.33166.1408585701.1622.leapsecs@leapsecond.com>
References: <mailman.33166.1408585701.1622.leapsecs@leapsecond.com>
Message-ID: <587CEF43-4770-40BF-98DF-9EC5BAF40E32@develooper.com>


> On Aug 20, 2014, at 18:48, leapsecs-request at leapsecond.com wrote:
> 
> "Dropping Leap Seconds" is something like burning great libraries.

That's a very particular opinion. I'd compare it to adding decimal digits to Pi instead of just saying 3 is accurate enough.

:-)


Ask

-- 
http://askask.com/

From brooks at edlmax.com  Wed Aug 20 23:28:20 2014
From: brooks at edlmax.com (Brooks Harris)
Date: Wed, 20 Aug 2014 23:28:20 -0400
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <87E90E2B-254B-4741-BB86-E2D9BD46EA5A@bsdimp.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
 <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>
 <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
 <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>
 <53F54E23.4020302@edlmax.com>
 <87E90E2B-254B-4741-BB86-E2D9BD46EA5A@bsdimp.com>
Message-ID: <53F56754.8050108@edlmax.com>

On 2014-08-20 10:23 PM, Warner Losh wrote:
> On Aug 20, 2014, at 7:40 PM, Brooks Harris <brooks at edlmax.com> wrote:
>
>> Since the beginning of civilization society has pursued the goal of perfect timekeeping. UTC is one of the great intellectual achievements of mankind.
>>
>> The difficulties with Leap Seconds are rooted in computer standards and implementations, not theory. We must strive to advance the state of the art, not abandon 4500 years of timekeeping history just because its difficult. Ceaser didn't quit. Pope Gregory didn't quit. Harrison didn't quit. Newcomb didn't quit.
>>
>> "Dropping Leap Seconds" is something like burning great libraries.
> Not sure I buy this hyperbole.

That's the fun of it!

> Leap seconds suffer from many minor issues that are only going to increase as we get more and more connected.

That's where an effort to consolidate the specifications and remove the 
flaws in computer standards could lead to uniform implementations.

> The stubborn refusal for any changes in the current implementation has me thinking of them as less than great libraries, and more as pebbles in my shoes.
I see the "pebbles in my shoes" as the flaws in standards and 
implementations. They are sharp and painful, to be sure, but abandoning 
Leap Seconds dismisses the history of timekeeping and, by itself, won't 
eliminate the pain anyway - you'll still need to reform the computer 
standards. Reform them to support Leap Seconds and we've advanced the 
state of the art rather than returning to flat land.
> There are many better ways to implement them, and "perfect timekeeping" always begs the question of "perfect for whom." De we align them with the day or the year? If we pick one over the other, the other gets out of sync.
The day, as has always been the traditional goal. That's why leap years 
and UTC with Leap Seconds in the first place, right?

-Brooks

>
> Warner
>
>> -Brooks
>>
>> On 2014-08-20 04:02 PM, Preben N?rager wrote:
>>> OMG its 290091200278565000. With THAT my proposal still stands :-)
>>>
>>>
>>> 2014-08-20 21:48 GMT+02:00 Keith Winstein <keithw at cs.stanford.edu>:
>>> Check that multiplication... :-)
>>>
>>> On Wed, Aug 20, 2014 at 2:42 PM, Preben N?rager <samp5087 at gmail.com> wrote:
>>>> I can not edit the numbers in my initial post, but I can do it here, and
>>>> with that my proposel still stands: Drop the leap second, and continue UTC
>>>> without leap
>>>> seconds, so that 1 mean solar year is defined as the
>>>> duration of 290091175979732 [31556925,9747x9192631770] periods of
>>>>
>>>> radiation in the caesium atom
>>>>
>>>>
>>>>
>>>> 2014-08-20 16:43 GMT+02:00 Keith Winstein <keithw at mit.edu>:
>>>>
>>>>> To be a pedant [but if you can't be one on the leapsecs mailing
>>>>> list...], the SI second is *9192631770* periods of the radiation etc.
>>>>> Your figure is high by 1000.
>>>>>
>>>>> On Wed, Aug 20, 2014 at 9:22 AM, Preben N?rager <samp5087 at gmail.com>
>>>>> wrote:
>>>>>> In the discussion about whether or not to drop the leap second, I think
>>>>>> it
>>>>>> is not a question about solar time or not solar time. It is in other
>>>>>> words
>>>>>> not a question about either solar time or atomic time.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If we drop the leap second it will be in favour of another timescale,
>>>>>> which
>>>>>> uses only atomic clocks to tell the time, but the time in that other
>>>>>> timescale will still be based upon a kind of solar time.
>>>>>>
>>>>>>
>>>>>>
>>>>>> About a hundred years ago it was decided, that the mean solar year, and
>>>>>> not
>>>>>> the mean solar day, should be the unit of international time.
>>>>>>
>>>>>>
>>>>>>
>>>>>> In 1960 the second was defined as 1/31556925,9747 of the mean solar
>>>>>> year,
>>>>>> and in 1967 the second was redefined [equally in length to the
>>>>>> previously
>>>>>> defined second] as the duration of 9192632770 periods of radiation.
>>>>>>
>>>>>>
>>>>>>
>>>>>> When the second was defined in 1960 it was defined as a fraction of the
>>>>>> so-called tropical year. That was a mistake of wording. The tropical
>>>>>> year is
>>>>>> a measurement of the solar longitude on the ecliptic, but the
>>>>>> international
>>>>>> definition of the second is not based upon measurement of the solar
>>>>>> longitude on the ecliptic.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The definition of the second is based upon Newcomb's theory of the solar
>>>>>> system, and in that theory it is the barycenter of the solar system, and
>>>>>> not
>>>>>> the center of the sun, which defines the length of the solar year.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The length of the solar year, according to Newcomb's theory, is the time
>>>>>> for
>>>>>> the longitude of the barycenter of the solar system to increase 360
>>>>>> decrees.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The solar year, thus defined, can be measured either for one year, or
>>>>>> for an
>>>>>> average of years.
>>>>>>
>>>>>>
>>>>>> But the 1960 and the 1967 definition of the second can also be used as
>>>>>> an
>>>>>> international definition of the mean solar year.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I think we should drop the leap second, and continue UTC without leap
>>>>>> seconds as TI [International Time], so that 1 mean solar year is the
>>>>>> duration of 290091231835491000 [31556925,9747x9192632770] periods of
>>>>>> radiation in the caesium atom.
>>>>>>
>>>>>> _______________________________________________
>>>>>> LEAPSECS mailing list
>>>>>> LEAPSECS at leapsecond.com
>>>>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>>>>>
>>>>> _______________________________________________
>>>>> LEAPSECS mailing list
>>>>> LEAPSECS at leapsecond.com
>>>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>>>
>>>
>>>
>>> _______________________________________________
>>> LEAPSECS mailing list
>>>
>>> LEAPSECS at leapsecond.com
>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> http://six.pairlist.net/mailman/listinfo/leapsecs
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/2f9fefd6/attachment-0001.html>

From imp at bsdimp.com  Wed Aug 20 23:35:26 2014
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 20 Aug 2014 21:35:26 -0600
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <587CEF43-4770-40BF-98DF-9EC5BAF40E32@develooper.com>
References: <mailman.33166.1408585701.1622.leapsecs@leapsecond.com>
 <587CEF43-4770-40BF-98DF-9EC5BAF40E32@develooper.com>
Message-ID: <E95E3DFB-B8C8-4C0A-AAB9-1E8AD8C40506@bsdimp.com>


On Aug 20, 2014, at 8:16 PM, Ask Bj?rn Hansen <ask at develooper.com> wrote:

> 
>> On Aug 20, 2014, at 18:48, leapsecs-request at leapsecond.com wrote:
>> 
>> "Dropping Leap Seconds" is something like burning great libraries.
> 
> That's a very particular opinion. I'd compare it to adding decimal digits to Pi instead of just saying 3 is accurate enough.

A more proper analogy would be using 3.141593 instead of 3.1415926?

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/7515aff4/attachment.pgp>

From imp at bsdimp.com  Wed Aug 20 23:57:51 2014
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 20 Aug 2014 21:57:51 -0600
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <53F56754.8050108@edlmax.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
 <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>
 <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
 <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>
 <53F54E23.4020302@edlmax.com>
 <87E90E2B-254B-4741-BB86-E2D9BD46EA5A@bsdimp.com>
 <53F56754.8050108@edlmax.com>
Message-ID: <E81BC843-402C-452B-9C65-17477BD65426@bsdimp.com>


On Aug 20, 2014, at 9:28 PM, Brooks Harris <brooks at edlmax.com> wrote:

> On 2014-08-20 10:23 PM, Warner Losh wrote:
>> On Aug 20, 2014, at 7:40 PM, Brooks Harris <brooks at edlmax.com>
>>  wrote:
>> 
>> 
>>> Since the beginning of civilization society has pursued the goal of perfect timekeeping. UTC is one of the great intellectual achievements of mankind.
>>> 
>>> The difficulties with Leap Seconds are rooted in computer standards and implementations, not theory. We must strive to advance the state of the art, not abandon 4500 years of timekeeping history just because its difficult. Ceaser didn't quit. Pope Gregory didn't quit. Harrison didn't quit. Newcomb didn't quit.
>>> 
>>> "Dropping Leap Seconds" is something like burning great libraries.
>>> 
>> Not sure I buy this hyperbole. 
> 
> That's the fun of it!
> 
>> Leap seconds suffer from many minor issues that are only going to increase as we get more and more connected. 
> 
> That's where an effort to consolidate the specifications and remove the flaws in computer standards could lead to uniform implementations.

Absolutely. We get leap days right because we don?t have to hear from the pope?s astronomers every year to know if it will be a leap year or not. We know for thousands of years.

>> The stubborn refusal for any changes in the current implementation has me thinking of them as less than great libraries, and more as pebbles in my shoes. 
> I see the "pebbles in my shoes" as the flaws in standards and implementations. They are sharp and painful, to be sure, but abandoning Leap Seconds dismisses the history of timekeeping and, by itself, won't eliminate the pain anyway - you'll still need to reform the computer standards. Reform them to support Leap Seconds and we've advanced the state of the art rather than returning to flat land.

Yes. We need to reform leap seconds if there?s any hope of them remaining viable for the long haul. One way to reform them is to toss our hands up in the air, because we know eventually leap seconds are doomed to die due to the quadratic acceleration of the accumulation of the differences (wow, why didn?t I just say eventually, they will happen so fast that once a day won?t be enough). One way to help get rid of the pebbles is to make them more regular so people know they have to shake their shoes out more often.

IERS likely can predict out to about 3 years a 90% or 95% confidence interval on DUT1. Publishing longer range leap seconds would be one way to make it more regular, but that?s still an observational calendar (people have to measure and correct often).

Another thing we could do is say ?we?d like to keep things mostly in sync? over the next hundred years. We could say ?There will be a leap second every 18 months for the next 15 years.? and reevaluate 10 years out to correct any oversteering. With any PLL (and UTC is a PLL since it is steered to an unpredictable wobbly rock), the steering constant is important, as is the amount of error to steer out. With the current system, we know and measure the error to predict the best time for a steer.



>> There are many better ways to implement them, and ?perfect timekeeping? always begs the question of ?perfect for whom.? De we align them with the day or the year? If we pick one over the other, the other gets out of sync.
> The day, as has always been the traditional goal. That's why leap years and UTC with Leap Seconds in the first place, right?

Has it? Time of day precision smaller than hours has only been important since 1500 or so when clocks became accurate enough where minutes mattered and people started moving into the cities and working for others. This accelerated with the industrial revolution around 1800 as factories grew more numerous. Prior to that, they didn?t care what any clock said: it was light out, so you needed to be working the fields, it was dark, you should sleep. Most of the advances in time keeping were astronomers of various flavors understanding the heavenly bodies so they could predict the next eclipse or solstice. These events were much more important than time of day, since they governed when you?d plant your crops, harvest your crops, etc. All these events were annual in nature, hence the length of the year was more important until he calendar rules were standardized enough for people to forget about it as a solved problem. There are two different clocks regulating human activity that are running at different rates. Optimizing one will pessimize the other.

Warner

> -Brooks
> 
>> 
>> Warner
>> 
>> 
>>> -Brooks
>>> 
>>> On 2014-08-20 04:02 PM, Preben N?rager wrote:
>>> 
>>>> OMG its 290091200278565000. With THAT my proposal still stands :-)
>>>> 
>>>> 
>>>> 2014-08-20 21:48 GMT+02:00 Keith Winstein 
>>>> <keithw at cs.stanford.edu>
>>>> :
>>>> Check that multiplication... :-)
>>>> 
>>>> On Wed, Aug 20, 2014 at 2:42 PM, Preben N?rager 
>>>> <samp5087 at gmail.com>
>>>>  wrote:
>>>> 
>>>>> I can not edit the numbers in my initial post, but I can do it here, and
>>>>> with that my proposel still stands: Drop the leap second, and continue UTC
>>>>> without leap
>>>>> seconds, so that 1 mean solar year is defined as the
>>>>> duration of 290091175979732 [31556925,9747x9192631770] periods of
>>>>> 
>>>>> radiation in the caesium atom
>>>>> 
>>>>> 
>>>>> 
>>>>> 2014-08-20 16:43 GMT+02:00 Keith Winstein 
>>>>> <keithw at mit.edu>
>>>>> :
>>>>> 
>>>>> 
>>>>>> To be a pedant [but if you can't be one on the leapsecs mailing
>>>>>> list...], the SI second is *9192631770* periods of the radiation etc.
>>>>>> Your figure is high by 1000.
>>>>>> 
>>>>>> On Wed, Aug 20, 2014 at 9:22 AM, Preben N?rager 
>>>>>> <samp5087 at gmail.com>
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> In the discussion about whether or not to drop the leap second, I think
>>>>>>> it
>>>>>>> is not a question about solar time or not solar time. It is in other
>>>>>>> words
>>>>>>> not a question about either solar time or atomic time.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> If we drop the leap second it will be in favour of another timescale,
>>>>>>> which
>>>>>>> uses only atomic clocks to tell the time, but the time in that other
>>>>>>> timescale will still be based upon a kind of solar time.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> About a hundred years ago it was decided, that the mean solar year, and
>>>>>>> not
>>>>>>> the mean solar day, should be the unit of international time.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> In 1960 the second was defined as 1/31556925,9747 of the mean solar
>>>>>>> year,
>>>>>>> and in 1967 the second was redefined [equally in length to the
>>>>>>> previously
>>>>>>> defined second] as the duration of 9192632770 periods of radiation.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> When the second was defined in 1960 it was defined as a fraction of the
>>>>>>> so-called tropical year. That was a mistake of wording. The tropical
>>>>>>> year is
>>>>>>> a measurement of the solar longitude on the ecliptic, but the
>>>>>>> international
>>>>>>> definition of the second is not based upon measurement of the solar
>>>>>>> longitude on the ecliptic.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> The definition of the second is based upon Newcomb's theory of the solar
>>>>>>> system, and in that theory it is the barycenter of the solar system, and
>>>>>>> not
>>>>>>> the center of the sun, which defines the length of the solar year.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> The length of the solar year, according to Newcomb?s theory, is the time
>>>>>>> for
>>>>>>> the longitude of the barycenter of the solar system to increase 360
>>>>>>> decrees.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> The solar year, thus defined, can be measured either for one year, or
>>>>>>> for an
>>>>>>> average of years.
>>>>>>> 
>>>>>>> 
>>>>>>> But the 1960 and the 1967 definition of the second can also be used as
>>>>>>> an
>>>>>>> international definition of the mean solar year.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> I think we should drop the leap second, and continue UTC without leap
>>>>>>> seconds as TI [International Time], so that 1 mean solar year is the
>>>>>>> duration of 290091231835491000 [31556925,9747x9192632770] periods of
>>>>>>> radiation in the caesium atom.
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> LEAPSECS mailing list
>>>>>>> 
>>>>>>> LEAPSECS at leapsecond.com
>>>>>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> _______________________________________________
>>>>>> LEAPSECS mailing list
>>>>>> 
>>>>>> LEAPSECS at leapsecond.com
>>>>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> LEAPSECS mailing list
>>>> 
>>>> 
>>>> LEAPSECS at leapsecond.com
>>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>> _______________________________________________
>>> LEAPSECS mailing list
>>> 
>>> LEAPSECS at leapsecond.com
>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>> 
>> 
>> _______________________________________________
>> LEAPSECS mailing list
>> 
>> LEAPSECS at leapsecond.com
>> http://six.pairlist.net/mailman/listinfo/leapsecs
> 
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/be6aaa55/attachment.pgp>

From sla at ucolick.org  Wed Aug 20 23:47:30 2014
From: sla at ucolick.org (Steve Allen)
Date: Wed, 20 Aug 2014 20:47:30 -0700
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <53F56754.8050108@edlmax.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
 <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>
 <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
 <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>
 <53F54E23.4020302@edlmax.com>
 <87E90E2B-254B-4741-BB86-E2D9BD46EA5A@bsdimp.com>
 <53F56754.8050108@edlmax.com>
Message-ID: <20140821034730.GA26615@ucolick.org>

On Wed 2014-08-20T23:28:20 -0400, Brooks Harris hath writ:
> The day, as has always been the traditional goal. That's why leap
> years and UTC with Leap Seconds in the first place, right?

Yes.  The IAU made that plain 50 years ago when they published
http://www.ucolick.org/~sla/leapsecs/note1964en.html
because as seen in point 5, they insisted that radio time signals give
UT.

What's stunning to me is that this year the IAU working group on the
redefinition of UTC quoted that in a response to the ITU-R request in
WRC-15 Agenda Item 1.14, but the document from the working group was
never forwarded to the ITU-R.  So the IAU has refused to acknowledge
its role in bringing about the current situation.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From seaman at noao.edu  Thu Aug 21 00:27:53 2014
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 20 Aug 2014 21:27:53 -0700
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <E95E3DFB-B8C8-4C0A-AAB9-1E8AD8C40506@bsdimp.com>
References: <mailman.33166.1408585701.1622.leapsecs@leapsecond.com>
 <587CEF43-4770-40BF-98DF-9EC5BAF40E32@develooper.com>
 <E95E3DFB-B8C8-4C0A-AAB9-1E8AD8C40506@bsdimp.com>
Message-ID: <73F09F6E-9665-4102-AB2F-9F6AAD49ED84@noao.edu>

Ask Bj?rn Hansen writes:

>> I'd compare it to adding decimal digits to Pi instead of just saying 3 is accurate enough.

Warner Losh says:

> A more proper analogy would be using 3.141593 instead of 3.1415926?

Proper analogies, is it?  More like 2.7182818 - the functional forms differ.  To do math, both ? and e are necessary:

	

Rob


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/1e331d09/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f897005615c391e14cd50112cda44665.png
Type: image/png
Size: 403 bytes
Desc: not available
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140820/1e331d09/attachment-0001.png>

From brooks at edlmax.com  Thu Aug 21 00:41:00 2014
From: brooks at edlmax.com (Brooks Harris)
Date: Thu, 21 Aug 2014 00:41:00 -0400
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <E81BC843-402C-452B-9C65-17477BD65426@bsdimp.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
 <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>
 <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
 <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>
 <53F54E23.4020302@edlmax.com>
 <87E90E2B-254B-4741-BB86-E2D9BD46EA5A@bsdimp.com>
 <53F56754.8050108@edlmax.com>
 <E81BC843-402C-452B-9C65-17477BD65426@bsdimp.com>
Message-ID: <53F5785C.9010805@edlmax.com>

On 2014-08-20 11:57 PM, Warner Losh wrote:
> On Aug 20, 2014, at 9:28 PM, Brooks Harris <brooks at edlmax.com> wrote:
>
>> On 2014-08-20 10:23 PM, Warner Losh wrote:
>>> On Aug 20, 2014, at 7:40 PM, Brooks Harris <brooks at edlmax.com>
>>>   wrote:
>>>
>>>
>>>> Since the beginning of civilization society has pursued the goal of perfect timekeeping. UTC is one of the great intellectual achievements of mankind.
>>>>
>>>> The difficulties with Leap Seconds are rooted in computer standards and implementations, not theory. We must strive to advance the state of the art, not abandon 4500 years of timekeeping history just because its difficult. Ceaser didn't quit. Pope Gregory didn't quit. Harrison didn't quit. Newcomb didn't quit.
>>>>
>>>> "Dropping Leap Seconds" is something like burning great libraries.
>>>>
>>> Not sure I buy this hyperbole.
>> That's the fun of it!
>>
>>> Leap seconds suffer from many minor issues that are only going to increase as we get more and more connected.
>> That's where an effort to consolidate the specifications and remove the flaws in computer standards could lead to uniform implementations.
> Absolutely. We get leap days right because we don't have to hear from the pope's astronomers every year to know if it will be a leap year or not. We know for thousands of years.
>
>>> The stubborn refusal for any changes in the current implementation has me thinking of them as less than great libraries, and more as pebbles in my shoes.
>> I see the "pebbles in my shoes" as the flaws in standards and implementations. They are sharp and painful, to be sure, but abandoning Leap Seconds dismisses the history of timekeeping and, by itself, won't eliminate the pain anyway - you'll still need to reform the computer standards. Reform them to support Leap Seconds and we've advanced the state of the art rather than returning to flat land.
> Yes. We need to reform leap seconds if there's any hope of them remaining viable for the long haul. One way to reform them is to toss our hands up in the air, because we know eventually leap seconds are doomed to die due to the quadratic acceleration of the accumulation of the differences (wow, why didn't I just say eventually, they will happen so fast that once a day won't be enough). One way to help get rid of the pebbles is to make them more regular so people know they have to shake their shoes out more often.
>
> IERS likely can predict out to about 3 years a 90% or 95% confidence interval on DUT1. Publishing longer range leap seconds would be one way to make it more regular, but that's still an observational calendar (people have to measure and correct often).
>
> Another thing we could do is say "we'd like to keep things mostly in sync" over the next hundred years. We could say "There will be a leap second every 18 months for the next 15 years." and reevaluate 10 years out to correct any oversteering. With any PLL (and UTC is a PLL since it is steered to an unpredictable wobbly rock), the steering constant is important, as is the amount of error to steer out. With the current system, we know and measure the error to predict the best time for a steer.
>
>
>
>>> There are many better ways to implement them, and "perfect timekeeping" always begs the question of "perfect for whom." De we align them with the day or the year? If we pick one over the other, the other gets out of sync.
>> The day, as has always been the traditional goal. That's why leap years and UTC with Leap Seconds in the first place, right?
> Has it? Time of day precision smaller than hours has only been important since 1500 or so when clocks became accurate enough where minutes mattered and people started moving into the cities and working for others. This accelerated with the industrial revolution around 1800 as factories grew more numerous. Prior to that, they didn't care what any clock said: it was light out, so you needed to be working the fields, it was dark, you should sleep. Most of the advances in time keeping were astronomers of various flavors understanding the heavenly bodies so they could predict the next eclipse or solstice. These events were much more important than time of day, since they governed when you'd plant your crops, harvest your crops, etc. All these events were annual in nature, hence the length of the year was more important until he calendar rules were standardized enough for people to forget about it as a solved problem.

Thank you Aloysius Lilius!

All true, but there are other important parts in the story. There was 
the sun dial. Cartography. Navigation and the longitude problem. The 
chronometer. Time was kept by "noon", then "midnight". Coordinating 
activity, railroad schedules, the Greenwich meridian, local time. The 
day has been a central theme in timekeeping too. Much of the effort was 
reconciling the day with other events. And UTC with Leap Seconds is the 
culmination of those efforts.


> There are two different clocks regulating human activity that are running at different rates. Optimizing one will pessimize the other.
>
> Warner
>
>> -Brooks
>>
>>> Warner
>>>
>>>
>>>> -Brooks
>>>>
>>>> On 2014-08-20 04:02 PM, Preben N?rager wrote:
>>>>
>>>>> OMG its 290091200278565000. With THAT my proposal still stands :-)
>>>>>
>>>>>
>>>>> 2014-08-20 21:48 GMT+02:00 Keith Winstein
>>>>> <keithw at cs.stanford.edu>
>>>>> :
>>>>> Check that multiplication... :-)
>>>>>
>>>>> On Wed, Aug 20, 2014 at 2:42 PM, Preben N?rager
>>>>> <samp5087 at gmail.com>
>>>>>   wrote:
>>>>>
>>>>>> I can not edit the numbers in my initial post, but I can do it here, and
>>>>>> with that my proposel still stands: Drop the leap second, and continue UTC
>>>>>> without leap
>>>>>> seconds, so that 1 mean solar year is defined as the
>>>>>> duration of 290091175979732 [31556925,9747x9192631770] periods of
>>>>>>
>>>>>> radiation in the caesium atom
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2014-08-20 16:43 GMT+02:00 Keith Winstein
>>>>>> <keithw at mit.edu>
>>>>>> :
>>>>>>
>>>>>>
>>>>>>> To be a pedant [but if you can't be one on the leapsecs mailing
>>>>>>> list...], the SI second is *9192631770* periods of the radiation etc.
>>>>>>> Your figure is high by 1000.
>>>>>>>
>>>>>>> On Wed, Aug 20, 2014 at 9:22 AM, Preben N?rager
>>>>>>> <samp5087 at gmail.com>
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> In the discussion about whether or not to drop the leap second, I think
>>>>>>>> it
>>>>>>>> is not a question about solar time or not solar time. It is in other
>>>>>>>> words
>>>>>>>> not a question about either solar time or atomic time.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> If we drop the leap second it will be in favour of another timescale,
>>>>>>>> which
>>>>>>>> uses only atomic clocks to tell the time, but the time in that other
>>>>>>>> timescale will still be based upon a kind of solar time.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> About a hundred years ago it was decided, that the mean solar year, and
>>>>>>>> not
>>>>>>>> the mean solar day, should be the unit of international time.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In 1960 the second was defined as 1/31556925,9747 of the mean solar
>>>>>>>> year,
>>>>>>>> and in 1967 the second was redefined [equally in length to the
>>>>>>>> previously
>>>>>>>> defined second] as the duration of 9192632770 periods of radiation.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> When the second was defined in 1960 it was defined as a fraction of the
>>>>>>>> so-called tropical year. That was a mistake of wording. The tropical
>>>>>>>> year is
>>>>>>>> a measurement of the solar longitude on the ecliptic, but the
>>>>>>>> international
>>>>>>>> definition of the second is not based upon measurement of the solar
>>>>>>>> longitude on the ecliptic.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The definition of the second is based upon Newcomb's theory of the solar
>>>>>>>> system, and in that theory it is the barycenter of the solar system, and
>>>>>>>> not
>>>>>>>> the center of the sun, which defines the length of the solar year.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The length of the solar year, according to Newcomb's theory, is the time
>>>>>>>> for
>>>>>>>> the longitude of the barycenter of the solar system to increase 360
>>>>>>>> decrees.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The solar year, thus defined, can be measured either for one year, or
>>>>>>>> for an
>>>>>>>> average of years.
>>>>>>>>
>>>>>>>>
>>>>>>>> But the 1960 and the 1967 definition of the second can also be used as
>>>>>>>> an
>>>>>>>> international definition of the mean solar year.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I think we should drop the leap second, and continue UTC without leap
>>>>>>>> seconds as TI [International Time], so that 1 mean solar year is the
>>>>>>>> duration of 290091231835491000 [31556925,9747x9192632770] periods of
>>>>>>>> radiation in the caesium atom.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> LEAPSECS mailing list
>>>>>>>>
>>>>>>>> LEAPSECS at leapsecond.com
>>>>>>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> LEAPSECS mailing list
>>>>>>>
>>>>>>> LEAPSECS at leapsecond.com
>>>>>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>>>>
>>>>> _______________________________________________
>>>>> LEAPSECS mailing list
>>>>>
>>>>>
>>>>> LEAPSECS at leapsecond.com
>>>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>>> _______________________________________________
>>>> LEAPSECS mailing list
>>>>
>>>> LEAPSECS at leapsecond.com
>>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>>>
>>> _______________________________________________
>>> LEAPSECS mailing list
>>>
>>> LEAPSECS at leapsecond.com
>>> http://six.pairlist.net/mailman/listinfo/leapsecs
>> _______________________________________________
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
>> http://six.pairlist.net/mailman/listinfo/leapsecs
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140821/cac641c7/attachment.html>

From clive at davros.org  Thu Aug 21 03:06:06 2014
From: clive at davros.org (Clive D.W. Feather)
Date: Thu, 21 Aug 2014 08:06:06 +0100
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <E81BC843-402C-452B-9C65-17477BD65426@bsdimp.com>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
 <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>
 <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
 <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>
 <53F54E23.4020302@edlmax.com>
 <87E90E2B-254B-4741-BB86-E2D9BD46EA5A@bsdimp.com>
 <53F56754.8050108@edlmax.com>
 <E81BC843-402C-452B-9C65-17477BD65426@bsdimp.com>
Message-ID: <20140821070606.GD70159@davros.org>

Warner Losh said:
> Absolutely. We get leap days right because we don?t have to hear from the pope?s astronomers every year to know if it will be a leap year or not. We know for thousands of years.

And note that it was exactly that problem that led Caius Julius to reform
the calendar in the first place.

[...]
> Another thing we could do is [...]

Or we could decouple UTC from GMT and allow each country to decide when to
change its offset. That subsumes the whole problem into the summer/winter
time switch, or the "move past the International Date Line" switch, that
the whole world knows how to handle, even if they don't all do it.

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

From igb at batten.eu.org  Fri Aug 22 03:14:16 2014
From: igb at batten.eu.org (Ian Batten)
Date: Fri, 22 Aug 2014 08:14:16 +0100
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <20140821070606.GD70159@davros.org>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
 <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>
 <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
 <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>
 <53F54E23.4020302@edlmax.com>
 <87E90E2B-254B-4741-BB86-E2D9BD46EA5A@bsdimp.com>
 <53F56754.8050108@edlmax.com>
 <E81BC843-402C-452B-9C65-17477BD65426@bsdimp.com>
 <20140821070606.GD70159@davros.org>
Message-ID: <D23CE168-3B13-4A88-8D7B-176E34284ADE@batten.eu.org>


On 21 Aug 2014, at 08:06, Clive D.W. Feather <clive at davros.org> wrote:

> Warner Losh said:
>> Absolutely. We get leap days right because we don?t have to hear from the pope?s astronomers every year to know if it will be a leap year or not. We know for thousands of years.
> 
> And note that it was exactly that problem that led Caius Julius to reform
> the calendar in the first place.
> 
> [...]
>> Another thing we could do is [...]
> 
> Or we could decouple UTC from GMT and allow each country to decide when to
> change its offset. That subsumes the whole problem into the summer/winter
> time switch, or the "move past the International Date Line" switch, that
> the whole world knows how to handle, even if they don't all do it.

I attempted to blag my way onto the UK government consultation process, but let slip that I knew about the issue.  So I ended up as part of the expert panel at one of the meetings (the "England" one), and with the chair of ISPA and a couple of heavy hitters from the Royal Observatory diaspora.  

The meetings have now all finished and the report has gone to the minister, so I don't think I'm breaking any confidences in saying that the public opinion --- which was, after two days, astoundingly well informed and gives you faith in the idea of citizen's juries --- was to leave well alone.  ISPA, whose members now also include Google and other cloud/webserver people, made the standard argument used here: "it's a bit of a pain, and we need to improve standards and dissemination, but we can cope whichever way the decision goes".  When there's no strong driver to change, people inevitably opt for the status quo, and that's what will be in the summary that goes to the minister.

It'll be interesting to see the outcome in the UK does, in fact, vote to retain leap seconds but loses.  De jure UK time is still GMT, while de facto everyone uses UTC (even the "Greenwich Pips" are actually UTC).  But with |DUT1|<0.9s no one gets too excited about the inconsistency.  

ian


From samp5087 at gmail.com  Fri Aug 22 12:07:13 2014
From: samp5087 at gmail.com (=?UTF-8?Q?Preben_N=C3=B8rager?=)
Date: Fri, 22 Aug 2014 18:07:13 +0200
Subject: [LEAPSECS] Solar time: From mean solar days, to mean solar years
In-Reply-To: <20140821070606.GD70159@davros.org>
References: <CABM=Kgbin-hQa891RF3R-DLsDeyPTbOdGJVpqb+kJ_m4vCnZsw@mail.gmail.com>
 <CAMzhQmP+g8A-Em4roKew-ZpxU+_Q5p0EWpirZHySmmTjmb3s_Q@mail.gmail.com>
 <CABM=KgZwAevtr_zz=kaMNLSPC59cpc4zQBmcWp1UvaV5ctiv6g@mail.gmail.com>
 <CAMzhQmOoMW=6_m3VLO3yYciCNTcoEc_St5s2ivj7+LPY9Wr6jA@mail.gmail.com>
 <CABM=KgZXJeEAEv8JsV9dsSm_e3Ot3+rDW8BmBdVyREqsRqZNsw@mail.gmail.com>
 <53F54E23.4020302@edlmax.com>
 <87E90E2B-254B-4741-BB86-E2D9BD46EA5A@bsdimp.com>
 <53F56754.8050108@edlmax.com>
 <E81BC843-402C-452B-9C65-17477BD65426@bsdimp.com>
 <20140821070606.GD70159@davros.org>
Message-ID: <CABM=KgZ9ZyEZ6YM6NBFnt1_+Fu7w3MTH+SOKQOcVk59zx86RYg@mail.gmail.com>

There exist, in use, two differing definitions of the dynamical equinox.
The one is called the rotational equinox, and the other is called the
inertial equinox (Standish 1981, [
http://adsabs.harvard.edu/full/1981A%26A...101L..17S]). The IERS uses the
inertial equinox.


I differentiate between the solar year, where the dynamical inertial
equinox determines the length of the year and, and the tropical year, where
the dynamical rotational equinox determines the length of the year. I have
not seen any comments on this aspect of my post. There has so far mostly
been the usual comments, for or against the mean solar day as the ?natural?
unit of time.


I think there is a lot of resistance against dropping the leap second
because the SI second builds upon a new understanding of the solar year,
where the inertial equinox, and not the rotational equinox, determines the
length of the year. Religion has always used the rotational equinox to
determine time, and never used the barycenter of the solar system, because
measurement of the barycenter belongs to modern time. Therefore I think a
lot of resistance comes from religion.


Modern society shall use the barycenter of the solar system, and the
inertial equinox, to determine time (with help from atomic clocks). But the
tropical year, and the rotational equinox, will always be part of for
instance the dating of Easter.


2014-08-21 9:06 GMT+02:00 Clive D.W. Feather <clive at davros.org>:

> Warner Losh said:
> > Absolutely. We get leap days right because we don?t have to hear from
> the pope?s astronomers every year to know if it will be a leap year or not.
> We know for thousands of years.
>
> And note that it was exactly that problem that led Caius Julius to reform
> the calendar in the first place.
>
> [...]
> > Another thing we could do is [...]
>
> Or we could decouple UTC from GMT and allow each country to decide when to
> change its offset. That subsumes the whole problem into the summer/winter
> time switch, or the "move past the International Date Line" switch, that
> the whole world knows how to handle, even if they don't all do it.
>
> --
> Clive D.W. Feather          | If you lie to the compiler,
> Email: clive at davros.org     | it will get its revenge.
> Web: http://www.davros.org  |   - Henry Spencer
> Mobile: +44 7973 377646
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140822/8a982ed8/attachment.html>

From ashtongj at comcast.net  Sun Aug 24 19:03:34 2014
From: ashtongj at comcast.net (Gerard Ashton)
Date: Sun, 24 Aug 2014 19:03:34 -0400
Subject: [LEAPSECS] Leap second relationship to ISO 8601
Message-ID: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>

ISO 8601 is expensive; I obtained a copy before they started making it hard
to find copies on the web. The wording of the standard is convoluted. Does
anyone know if there is a highly-reputable, readable description of the
standard that explains the extent to which the various choices are required,
recommended, or merely allowed?

For example, if one wishes to use the format 2014-08-24, is it mandatory
that the day begin at midnight according to some unspecified local time?

If one wishes to specify the time, does the standard recommend 23:02Z over
07:03, or are they on an equal footing?

Is there a highly respected discussion anywhere of what to do about UTC
before leap seconds, or the period before the introduction of UTC, in ISO
8601 representations?

Gerry Ashton


From dot at dotat.at  Tue Aug 26 07:43:09 2014
From: dot at dotat.at (Tony Finch)
Date: Tue, 26 Aug 2014 12:43:09 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
Message-ID: <alpine.LSU.2.00.1408261230320.18897@hermes-1.csi.cam.ac.uk>

Gerard Ashton <ashtongj at comcast.net> wrote:

> For example, if one wishes to use the format 2014-08-24, is it mandatory
> that the day begin at midnight according to some unspecified local time?

ISO 8601 does not specify the time zone alignment of calendar days. It
allows you to identify a date in the abstract without being specific about
time of day, or to explicitly describe a 24 hour period using the interval
representation.

> If one wishes to specify the time, does the standard recommend 23:02Z over
> 07:03, or are they on an equal footing?

Those are different things. A time without a UTC designator or UTC
difference is a local time in an unspecified time zone.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

From seaman at noao.edu  Tue Aug 26 10:20:36 2014
From: seaman at noao.edu (Rob Seaman)
Date: Tue, 26 Aug 2014 07:20:36 -0700
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <alpine.LSU.2.00.1408261230320.18897@hermes-1.csi.cam.ac.uk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <alpine.LSU.2.00.1408261230320.18897@hermes-1.csi.cam.ac.uk>
Message-ID: <023CF2BF-E8AB-4A56-8655-CEF24C54CA6D@noao.edu>

On Aug 26, 2014, at 4:43 AM, Tony Finch <dot at dotat.at> wrote:

> Gerard Ashton <ashtongj at comcast.net> wrote:
> 
>> For example, if one wishes to use the format 2014-08-24, is it mandatory
>> that the day begin at midnight according to some unspecified local time?
> 
> ISO 8601 does not specify the time zone alignment of calendar days. It
> allows you to identify a date in the abstract without being specific about
> time of day, or to explicitly describe a 24 hour period using the interval
> representation.

A date is an integer.  A timestamp is a real.  (however represented)

>> If one wishes to specify the time, does the standard recommend 23:02Z over
>> 07:03, or are they on an equal footing?
> 
> Those are different things. A time without a UTC designator or UTC
> difference is a local time in an unspecified time zone.

Though the timezone might be implicit in your application.  ISO 8601 is not particularly friendly to 12-hour clock time, if that was what you were asking.

Rob


From dot at dotat.at  Tue Aug 26 10:44:07 2014
From: dot at dotat.at (Tony Finch)
Date: Tue, 26 Aug 2014 15:44:07 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <023CF2BF-E8AB-4A56-8655-CEF24C54CA6D@noao.edu>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <alpine.LSU.2.00.1408261230320.18897@hermes-1.csi.cam.ac.uk>
 <023CF2BF-E8AB-4A56-8655-CEF24C54CA6D@noao.edu>
Message-ID: <alpine.LSU.2.00.1408261542410.18897@hermes-1.csi.cam.ac.uk>

Rob Seaman <seaman at noao.edu> wrote:
>
> A date is an integer.  A timestamp is a real.  (however represented)

And this is a great example of why UTC is usually implemented incorrectly.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

From imp at bsdimp.com  Tue Aug 26 10:58:33 2014
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 26 Aug 2014 08:58:33 -0600
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <alpine.LSU.2.00.1408261542410.18897@hermes-1.csi.cam.ac.uk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <alpine.LSU.2.00.1408261230320.18897@hermes-1.csi.cam.ac.uk>
 <023CF2BF-E8AB-4A56-8655-CEF24C54CA6D@noao.edu>
 <alpine.LSU.2.00.1408261542410.18897@hermes-1.csi.cam.ac.uk>
Message-ID: <398F7F7D-C9DA-4E99-AE79-F35BD84680D7@bsdimp.com>


On Aug 26, 2014, at 8:44 AM, Tony Finch <dot at dotat.at> wrote:

> Rob Seaman <seaman at noao.edu> wrote:
>> 
>> A date is an integer.  A timestamp is a real.  (however represented)
> 
> And this is a great example of why UTC is usually implemented incorrectly.

I had a college that was graphing data that was supposed to have MJD as the X axis. The data was in UTC standard time stamps (including some days with 23:59:60).  We had a long argument about how to convert the time of day to a fractional time of day on days with leap seconds. In the end, it turned out the two graphs looked identical if you did it one way vs another, so he opted for the most complicated to implement :).

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140826/0288182d/attachment.pgp>

From brooks at edlmax.com  Tue Aug 26 12:09:20 2014
From: brooks at edlmax.com (Brooks Harris)
Date: Tue, 26 Aug 2014 12:09:20 -0400
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
Message-ID: <53FCB130.7090202@edlmax.com>

On 2014-08-24 07:03 PM, Gerard Ashton wrote:
> ISO 8601 is expensive; I obtained a copy before they started making it hard
> to find copies on the web. The wording of the standard is convoluted.

Yes it is, as is usually the case in standards due to the many voices 
that become part of it. In the case of 8601 this makes it difficult to 
identify the fact that it is *incomplete* in defining *comprehensive* 
date and time representation.

> Does
> anyone know if there is a highly-reputable, readable description of the
> standard that explains the extent to which the various choices are required,
> recommended, or merely allowed?

8601 is famous for its form(s) of character representation, especially 
its recommendation of the order being "most significant first" - 
YY-MM-DD hh:mm:ss. Yet perhaps its more important contribution is 
defining the date and time data elements it is representing.

But keep in mind it is all recommendation - there's no requirement of 
anything. Folks probably overlook the paragraph in the Scope -

"This International Standard does not assign any particular meaning or 
interpretation to any data element that
uses representations in accordance with this International Standard. 
Such meaning will be determined by the
context of the application."

8601 goes a long way toward defining the time and data elements, but it 
is unfortunately incomplete. Note it relies in turn, and normatively, on 
the IEC *vocabulary* documents, themselves even more obscure and 
difficult to obtain. (Throughout 8601 you'll notice references like 
"[IEC 60050-111]").

Studying this chain of provenance is also convoluted, and the upshot is 
to recognize how distressingly incomplete the underlying terms and 
definitions are, especially in regards to specifying "local time".

Its important to note 8601 is silent on how "Daylight Savings Time" is 
handled and provides no recommendation of how it might be indicated or 
represented. Looking closely you'll find there is no universal 
definition of "local time". In particular, 8601 implies use of "offset 
from UTC", as indication of "local time", but conflates this with 
Daylight Savings. For example, a date and time in New York City might be 
represented as 2014-07-04T00:00:00-05:00 which misses the fact that 
Daylight was in effect, or 2014-07-04T00:00:00-04:00 which misses the 
fact the the fixed timezone offset is -05:00.

Typically 8601 is interpreted as adhering to the "rules of UTC" 
(although, strictly, this too is not required). 8601 gives a brief 
definition of UTC, but the careful implementer will look to the 
literature to better understand it. Here you find a large number of 
standards bodies and specifications which together define "UTC". It is 
much more convoluted and complex than 8601. It has been characterized as 
"fractured". You may start with ITU RECOMMENDATION ITU-R TF.460-6, which 
will lead to the BIPM Annual Report on Time Activities, and to 
INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS), 
Bulletin C, amongst others. The deeper you go, the more complex it gets.

Add to this POSIX (time), the underlying heritage of most computer-based 
timekeeping systems. Note that POSIX's notion of "local time" is 
actually in direct conflict with the international standards. IEC 60050 
(and 8601) say that "Standard time" may or may not include "Daylight 
Savings" (or "summer time"), while POSIX separates them as STD and DST. 
This is better, that is, closer to "common use", but there are other 
deficiencies and ambiguities in the POSIX spec, especially regarding the 
definition of "The Epoch" and counting methods with regard to Leap Seconds.

Enter NTP. The NTP spec can be used to partly clarify Epochs and 
handling of Leap Seconds, but it too has deficiencies in Leap Second 
counting.

> For example, if one wishes to use the format 2014-08-24, is it mandatory
> that the day begin at midnight according to some unspecified local time?
>
> If one wishes to specify the time, does the standard recommend 23:02Z over
> 07:03, or are they on an equal footing?
>
> Is there a highly respected discussion anywhere of what to do about UTC
> before leap seconds, or the period before the introduction of UTC, in ISO
> 8601 representations?

The definition of "proleptic UTC" is controvesial. NTP does the best job 
of it. in my opinion, but watch out; its subtle.

Many efforts have been made to resolve these ambiguities, none 
universally accepted. See, for examples -

Date-Time Vocabulary (DTV) Version 1.0
http://www.omg.org/spec/DTV/1.0/PDF/

Time Ontology in OWL
http://www.w3.org/TR/owl-time/

All tolled, I think this is a pretty good characterization of the state 
of the art -

The Problem with Time & Timezones - Computerphile
https://www.youtube.com/watch?v=-5wpm-gesOY

-Brooks
>
> Gerry Ashton
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
>
>


From dot at dotat.at  Wed Aug 27 05:22:40 2014
From: dot at dotat.at (Tony Finch)
Date: Wed, 27 Aug 2014 10:22:40 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <53FCB130.7090202@edlmax.com>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
Message-ID: <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>

Brooks Harris <brooks at edlmax.com> wrote:
>
> Its important to note 8601 is silent on how "Daylight Savings Time" is handled
> and provides no recommendation of how it might be indicated or represented.

ISO 8601 does not represent daylight saving nor time zones.

> Looking closely you'll find there is no universal definition of "local time".
> In particular, 8601 implies use of "offset from UTC", as indication of "local
> time", but conflates this with Daylight Savings. For example, a date and time
> in New York City might be represented as 2014-07-04T00:00:00-05:00 which
> misses the fact that Daylight was in effect, or 2014-07-04T00:00:00-04:00
> which misses the fact the the fixed timezone offset is -05:00.

The former is incorrect.

> The definition of "proleptic UTC" is controvesial. NTP does the best job of
> it. in my opinion, but watch out; its subtle.

I did not think NTP had anything to say about proleptic UTC at all. Do you
have a specific reference?

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

From phk at phk.freebsd.dk  Wed Aug 27 05:26:01 2014
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 27 Aug 2014 09:26:01 +0000
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
Message-ID: <51489.1409131561@critter.freebsd.dk>

--------
In message <alpine.LSU.2.00.1408271011340.23119 at hermes-1.csi.cam.ac.uk>, Tony F
inch writes:
>Brooks Harris <brooks at edlmax.com> wrote:
>>
>> Its important to note 8601 is silent on how "Daylight Savings Time" is handled
>> and provides no recommendation of how it might be indicated or represented.
>
>ISO 8601 does not represent daylight saving nor time zones.

I'm told this was by design.

The intent was that you could always use an 8601 string without
reference to "external cultural databases".

-- 
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 brooks at edlmax.com  Wed Aug 27 09:52:22 2014
From: brooks at edlmax.com (Brooks Harris)
Date: Wed, 27 Aug 2014 09:52:22 -0400
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
Message-ID: <53FDE296.9070901@edlmax.com>

Hi Tony,


On 2014-08-27 05:22 AM, Tony Finch wrote:
> Brooks Harris <brooks at edlmax.com> wrote:
>> Its important to note 8601 is silent on how "Daylight Savings Time" is handled
>> and provides no recommendation of how it might be indicated or represented.
> ISO 8601 does not represent daylight saving nor time zones.

It can represent both, but incompletely, or ambiguously. The "time 
element" called "zone designator" conflates "offset from UTC" and 
"Daylight Savings offset" in the "time element" called "zone designator".

>
>> Looking closely you'll find there is no universal definition of "local time".
>> In particular, 8601 implies use of "offset from UTC", as indication of "local
>> time", but conflates this with Daylight Savings. For example, a date and time
>> in New York City might be represented as 2014-07-04T00:00:00-05:00 which
>> misses the fact that Daylight was in effect, or 2014-07-04T00:00:00-04:00
>> which misses the fact the the fixed timezone offset is -05:00.
> The former is incorrect.

Incorrect where? 2014-07-04T00:00:00-05:00 would have been correct in 
Chicago. We only know this because we know a-priori Daylight Savings was 
in effect in that jurisdiction. It was 2014-07-04T00:00:00-06:00 
"Mountain Daylight Time" while it was 2014-07-04T00:00:00-07:00 in 
Arizona, which does not observe Daylight Savings.

Strictly from the 8601 representation we don't know if Daylight was in 
effect or even if it is observed in the jurisdiction, so we can't 
distinguish the "fixed offset from UTC to the local jurisdiction".

Meantime POSIX (time) *does* record this distinction in STD and DST.

>
>> The definition of "proleptic UTC" is controvesial. NTP does the best job of
>> it. in my opinion, but watch out; its subtle.
> I did not think NTP had anything to say about proleptic UTC at all. Do you
> have a specific reference?

Network Time Protocol Version 4: Protocol and Algorithms Specification
http://www.ietf.org/rfc/rfc5905.txt

Section 6.  Data Types

" In the date and timestamp formats, the prime epoch, or base date of
    era 0, is 0 h 1 January 1900 UTC, when all bits are zero.  It should
    be noted that strictly speaking, UTC did not exist prior to 1 January
    1972, but it is convenient to assume it has existed for all eternity,
    even if all knowledge of historic leap seconds has been lost. "

This describes a proleptic UTC timescale that is *uncompensated for Leap 
Seconds*, that is, it extrapolates the Gregorian calendar counting 
method into the past from 1972-01-01T00:00:00Z (UTC).

Further, "Figure 4: Interesting Historic NTP Dates" shows that the NTP 
"prime epoch of era zero" is 2,272,060,800 seconds before 
1972-01-01T00:00:00Z (UTC).

Most explainations, and the spec itself, say that NTP does not account 
for Leap Seconds, and it does not, *explicitly*. Note, however, that 
2272060800 secs / 86400 = 26297 days *exactly*. There were 10 Leap 
Seconds in effect at 1972-01-01T00:00:00Z (UTC), so there must be 10 
Leap Seconds in effect at the NTP "prime epoch of era zero", "0 h 1 
January 1900 UTC".

-Brooks

>
> Tony.


From dot at dotat.at  Wed Aug 27 12:08:04 2014
From: dot at dotat.at (Tony Finch)
Date: Wed, 27 Aug 2014 17:08:04 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <53FDE296.9070901@edlmax.com>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
Message-ID: <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>

Brooks Harris <brooks at edlmax.com> wrote:
> On 2014-08-27 05:22 AM, Tony Finch wrote:
> >
> > ISO 8601 does not represent daylight saving nor time zones.
>
> It can represent both, but incompletely, or ambiguously. The "time element"
> called "zone designator" conflates "offset from UTC" and "Daylight Savings
> offset" in the "time element" called "zone designator".

The offset from UTC does not identify the time zone: many time zones can
have the same offset. The offset does not tell you whether DST is in
effect: you need to know the details of the time zone in order to work it
out.

> > > For example, a date and time in New York City might be represented
> > > as 2014-07-04T00:00:00-05:00 which misses the fact that Daylight was
> > > in effect, or 2014-07-04T00:00:00-04:00 which misses the fact the
> > > the fixed timezone offset is -05:00.
> >
> > The former is incorrect.
>
> Incorrect where?

The UTC offset in New York at that time was not -05:00 so that cannot be a
time in New York.

> Most explainations, and the spec itself, say that NTP does not account
> for Leap Seconds, and it does not, *explicitly*. Note, however, that
> 2272060800 secs / 86400 = 26297 days *exactly*. There were 10 Leap
> Seconds in effect at 1972-01-01T00:00:00Z (UTC), so there must be 10
> Leap Seconds in effect at the NTP "prime epoch of era zero", "0 h 1
> January 1900 UTC".

That reasoning is faulty. Figure 4 of RFC 5905 also says that the
NTP timestamp for 1999-12-31 is 3155587200, and
(3155587200-2272060800)/86400 is 10226 days exactly.

You cannot infer the number of leap seconds between two NTP or POSIX
time stamps, because both time scales handle leap seconds out of band.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

From phk at phk.freebsd.dk  Wed Aug 27 13:38:12 2014
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 27 Aug 2014 17:38:12 +0000
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
 <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
Message-ID: <6801.1409161092@critter.freebsd.dk>

--------
In message <alpine.LSU.2.00.1408271650570.23119 at hermes-1.csi.cam.ac.uk>, Tony F
inch writes:
>Brooks Harris <brooks at edlmax.com> wrote:

>> > > For example, a date and time in New York City might be represented
>> > > as 2014-07-04T00:00:00-05:00 [...]
>> >
>> > The former is incorrect.
>>
>> Incorrect where?
>
>The UTC offset in New York at that time was not -05:00 so that cannot be a
>time in New York.

You're missing the quiet genius of 8601 here:

Who said the date and time of the event which happened in New York
were represented on local timescale there at the time ?

It would have been if you had written some ...EST or ...DST, and
that would take you into the murky swamp of the olsen timezone
database.

By explicitly stating the UTC offset numerically, 8601 decouples
it from any cultural basis it might have had and becomes a standalone
representation of a moment in time.

-- 
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 brooks at edlmax.com  Wed Aug 27 22:59:08 2014
From: brooks at edlmax.com (Brooks Harris)
Date: Wed, 27 Aug 2014 22:59:08 -0400
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
 <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
Message-ID: <53FE9AFC.9070502@edlmax.com>

Hi Tony,

On 2014-08-27 12:08 PM, Tony Finch wrote:
> Brooks Harris<brooks at edlmax.com>  wrote:
>> On 2014-08-27 05:22 AM, Tony Finch wrote:
>>> ISO 8601 does not represent daylight saving nor time zones.
>> It can represent both, but incompletely, or ambiguously. The "time element"
>> called "zone designator" conflates "offset from UTC" and "Daylight Savings
>> offset" in the "time element" called "zone designator".
> The offset from UTC does not identify the time zone: many time zones can
> have the same offset. The offset does not tell you whether DST is in
> effect: you need to know the details of the time zone in order to work it
> out.

Yes, that's the point. You need to know many details which an 8601 
representation does not communicate.

>>>> For example, a date and time in New York City might be represented
>>>> as 2014-07-04T00:00:00-05:00 which misses the fact that Daylight was
>>>> in effect, or 2014-07-04T00:00:00-04:00 which misses the fact the
>>>> the fixed timezone offset is -05:00.
>>> The former is incorrect.
>> Incorrect where?
> The UTC offset in New York at that time was not -05:00 so that cannot be a
> time in New York.
Yes. But you only know that because you know the history of the Daylight 
Savings in that jurisdiction, again, not communicated by 8601.

>> Most explainations, and the spec itself, say that NTP does not account
>> for Leap Seconds, and it does not, *explicitly*. Note, however, that
>> 2272060800 secs / 86400 = 26297 days *exactly*. There were 10 Leap
>> Seconds in effect at 1972-01-01T00:00:00Z (UTC), so there must be 10
>> Leap Seconds in effect at the NTP "prime epoch of era zero", "0 h 1
>> January 1900 UTC".
> That reasoning is faulty.
I hope not :-\

> Figure 4 of RFC 5905 also says that the
> NTP timestamp for 1999-12-31 is 3155587200, and
> (3155587200-2272060800)/86400 is 10226 days exactly.
1999-12-31 is after 1972, and 32 Leap Seconds are in effect - 10 initial 
at 1972 plus 22 decreed inserts.

As Mills explains- http://www.eecis.udel.edu/~mills/leap.html

"Another way to describe this is to say there are as many NTP or POSIX 
timescales as historic leap seconds. In effect, a new timescale is 
reestablished after each new leap second. Thus, all previous leap 
seconds, not to mention the apparent origin of the timescale itself, 
lurch backward one second as each new timescale is established. "

The origin of this shifted NTP timescale on which 1999-12-31 is 
represented is 22 seconds before the original NTP "prime epoch". Thus, 
1999-12-31 (UTC) is 3155587222 seconds after the original NTP "prime 
epoch", but 3155587200 seconds after the *shifted* NTP origin in effect, 
which Figure 4 shows. The difference is 22 rather than 32 because 10 
Leap Seconds are in effect at the "prime epoch".

[ --------
Caution - Michael Deckers pointed out in an earlier email on the list 
(good catch!)-

   Please note that this table has to be read with caution.

   Besides the typo -678,491 for -678,941, one has to realize that
   "1 Jan -4712" is meant as a date in the Julian calendar, but
   all the other dates in column 1 must be taken as Gregorian calendar
   dates, even those before 1582-10-15 -- else the entries in
   columns 2,3,4 become incorrect. And this makes the entry
   in column 5 for the date 1582-10-04 incorrect.
------- ]

> You cannot infer the number of leap seconds between two NTP or POSIX
> time stamps, because both time scales handle leap seconds out of band.

Yes, all knowledge of leap seconds are lost in the counting mechanisms 
because of the NTP count "freeze" at the Leap Second insert (or 
over-count and reset for POSIX). Their origins shift with respect to the 
1972 UTC origin, the NTP "prime epoch", and the POSIX "The Epoch" 
("First day UNIX" in Figure 4) with each insert. I suppose you could 
call this "out of band".

-Brooks

> Tony.


From dot at dotat.at  Thu Aug 28 05:28:52 2014
From: dot at dotat.at (Tony Finch)
Date: Thu, 28 Aug 2014 10:28:52 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <6801.1409161092@critter.freebsd.dk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
 <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
 <6801.1409161092@critter.freebsd.dk>
Message-ID: <alpine.LSU.2.00.1408281021260.23119@hermes-1.csi.cam.ac.uk>

Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> >> > > For example, a date and time in New York City might be represented
> >> > > as 2014-07-04T00:00:00-05:00 [...]
> >> >
> >> > The former is incorrect.
> >>
> >> Incorrect where?
> >
> >The UTC offset in New York at that time was not -05:00 so that cannot be a
> >time in New York.
>
> You're missing the quiet genius of 8601 here:
>
> Who said the date and time of the event which happened in New York
> were represented on local timescale there at the time ?

I thought that is what Brooks was trying to do.

Obviously when ISO 8601 talks about local time it is leaving it to some
unspecified context to determine what locality the time belongs to; in
this discussion the locality is New York, and it would be particularly
contrary of Brooks to want to represent the time in New York using some
other place's local time.

> By explicitly stating the UTC offset numerically, 8601 decouples
> it from any cultural basis it might have had and becomes a standalone
> representation of a moment in time.

Right, and this is good for many purposes, e.g. recording times of events
now or in the past. However for events in the future (meetings etc.) you
need to record a time and a place, because the UTC offset and time zone
rules are not predictable.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

From ashtongj at comcast.net  Thu Aug 28 06:20:07 2014
From: ashtongj at comcast.net (Gerard Ashton)
Date: Thu, 28 Aug 2014 06:20:07 -0400
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <alpine.LSU.2.00.1408281021260.23119@hermes-1.csi.cam.ac.uk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
 <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
 <6801.1409161092@critter.freebsd.dk>
 <alpine.LSU.2.00.1408281021260.23119@hermes-1.csi.cam.ac.uk>
Message-ID: <000601cfc2a9$a46ad4c0$ed407e40$@comcast.net>

Tony Finch wrote

> Right, and this is good for many purposes, e.g. recording times of events
now or in the past. However for events in the future (meetings etc.) you
need to record a time and a place, because the UTC offset and time zone
rules are not predictable.

Even better, local time can be used to specify recurring meetings which
begin at the same local time, but different UTC times, because of daylight
saving time. ISO 8601 has a notation for recurring events, although I have
not mastered it.

Gerry Ashton



From clive at davros.org  Thu Aug 28 07:43:25 2014
From: clive at davros.org (Clive D.W. Feather)
Date: Thu, 28 Aug 2014 12:43:25 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <alpine.LSU.2.00.1408281021260.23119@hermes-1.csi.cam.ac.uk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
 <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
 <6801.1409161092@critter.freebsd.dk>
 <alpine.LSU.2.00.1408281021260.23119@hermes-1.csi.cam.ac.uk>
Message-ID: <20140828114325.GB65927@davros.org>

Tony Finch said:
> However for events in the future (meetings etc.) you
> need to record a time and a place, because the UTC offset and time zone
> rules are not predictable.

More precisely, the accuracy of predictions varies.

(I'd have a lot of confidence in the 2005 offsets for England. Rather less
for those in Palestine.)

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

From phk at phk.freebsd.dk  Thu Aug 28 08:10:10 2014
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 28 Aug 2014 12:10:10 +0000
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <alpine.LSU.2.00.1408281021260.23119@hermes-1.csi.cam.ac.uk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
 <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
 <6801.1409161092@critter.freebsd.dk>
 <alpine.LSU.2.00.1408281021260.23119@hermes-1.csi.cam.ac.uk>
Message-ID: <1423.1409227810@critter.freebsd.dk>

--------
In message <alpine.LSU.2.00.1408281021260.23119 at hermes-1.csi.cam.ac.uk>, Tony F
inch writes:

>However for events in the future (meetings etc.) you
>need to record a time and a place, because the UTC offset and time zone
>rules are not predictable.

The main problem here is to get people to give you enough information
in the first place.

For instance:

I add a meeting to my calendar at 10:00 day after tomorrow.

Tomorrow I fly to Ulan Batoor.

When is the meeting ?

It could be a meeting in Ulan Batoor, it could be a phone-meeting
back in Denmark or it could be a teleconference with Melbourne.

Many heuristic attempts have been made to "DWIM" and all fails.

8601 is not even attempting to get anywhere near that problem,
all it tries to do, is ensure that when I write a timestamp
with some number of components, you will read it the same way
and get the same components with the same numerical values.

But 8601 doesn't care or try to make sense of what the numbers might mean.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
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 brooks at edlmax.com  Thu Aug 28 08:30:46 2014
From: brooks at edlmax.com (Brooks Harris)
Date: Thu, 28 Aug 2014 08:30:46 -0400
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <1423.1409227810@critter.freebsd.dk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
 <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
 <6801.1409161092@critter.freebsd.dk>
 <alpine.LSU.2.00.1408281021260.23119@hermes-1.csi.cam.ac.uk>
 <1423.1409227810@critter.freebsd.dk>
Message-ID: <53FF20F6.2050505@edlmax.com>


On 2014-08-28 08:10 AM, Poul-Henning Kamp wrote:
> --------
> In message <alpine.LSU.2.00.1408281021260.23119 at hermes-1.csi.cam.ac.uk>, Tony F
> inch writes:
>
>> However for events in the future (meetings etc.) you
>> need to record a time and a place, because the UTC offset and time zone
>> rules are not predictable.
> The main problem here is to get people to give you enough information
> in the first place.
>
> For instance:
>
> I add a meeting to my calendar at 10:00 day after tomorrow.
>
> Tomorrow I fly to Ulan Batoor.
>
> When is the meeting ?
>
> It could be a meeting in Ulan Batoor, it could be a phone-meeting
> back in Denmark or it could be a teleconference with Melbourne.
>
> Many heuristic attempts have been made to "DWIM" and all fails.
>
> 8601 is not even attempting to get anywhere near that problem,
> all it tries to do, is ensure that when I write a timestamp
> with some number of components, you will read it the same way
> and get the same components with the same numerical values.
>
> But 8601 doesn't care or try to make sense of what the numbers might mean.
>
>
An organization I work with has been using a web-based meeting 
scheduling calendar that gives meeting date-time notifications.

Recently it has been announcing meetings as, for example -

"When: Wednesday, September 24, 2014 11:00 AM-12:30 PM. (UTC-05:00) 
Eastern Time (US & Canada)"

Of course Daylight is in effect on the east coast, so its completely 
wrong. What is intended is 2014-09-24T12:00-04:00 (noon, "Eastern 
Daylight Time").

Ironic that a web site serving a working group concerned with 
timekeeping gets this go badly confused.

It would better if 8601 provided a DST flag, so you might have something 
like 2014-09-24T12:00-05:00S1, where "-05:00" is the fixed offset from 
UTC for the locality, and "S1" means "(Daylight) *S*avings in effect".

-Brooks





From clive at davros.org  Thu Aug 28 08:37:35 2014
From: clive at davros.org (Clive D.W. Feather)
Date: Thu, 28 Aug 2014 13:37:35 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <53FF20F6.2050505@edlmax.com>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
 <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
 <6801.1409161092@critter.freebsd.dk>
 <alpine.LSU.2.00.1408281021260.23119@hermes-1.csi.cam.ac.uk>
 <1423.1409227810@critter.freebsd.dk> <53FF20F6.2050505@edlmax.com>
Message-ID: <20140828123735.GC76389@davros.org>

Brooks Harris said:
> An organization I work with has been using a web-based meeting 
> scheduling calendar that gives meeting date-time notifications.
> 
> Recently it has been announcing meetings as, for example -
> 
> "When: Wednesday, September 24, 2014 11:00 AM-12:30 PM. (UTC-05:00) 
> Eastern Time (US & Canada)"
> 
> Of course Daylight is in effect on the east coast, so its completely 
> wrong. What is intended is 2014-09-24T12:00-04:00 (noon, "Eastern 
> Daylight Time").

Microsoft's calendaring stuff does that. I keep getting stuff that says
it's at (say) 10:00 UTC, plus "the UTC offset doesn't take account of
daylight savings time", when what it means is 10:00 BST.

Even worse is the ones that say 10:00 UTC+01:00, which actually mean 09:00
BST.

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

From dot at dotat.at  Thu Aug 28 09:54:46 2014
From: dot at dotat.at (Tony Finch)
Date: Thu, 28 Aug 2014 14:54:46 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <53FE9AFC.9070502@edlmax.com>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
 <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
 <53FE9AFC.9070502@edlmax.com>
Message-ID: <alpine.LSU.2.00.1408281440200.29365@hermes-1.csi.cam.ac.uk>

Brooks Harris <brooks at edlmax.com> wrote:
>
> > > Most explainations, and the spec itself, say that NTP does not account
> > > for Leap Seconds, and it does not, *explicitly*. Note, however, that
> > > 2272060800 secs / 86400 = 26297 days *exactly*. There were 10 Leap
> > > Seconds in effect at 1972-01-01T00:00:00Z (UTC), so there must be 10
> > > Leap Seconds in effect at the NTP "prime epoch of era zero", "0 h 1
> > > January 1900 UTC".
> > That reasoning is faulty.
> I hope not :-\
>
> > Figure 4 of RFC 5905 also says that the
> > NTP timestamp for 1999-12-31 is 3155587200, and
> > (3155587200-2272060800)/86400 is 10226 days exactly.
> 1999-12-31 is after 1972, and 32 Leap Seconds are in effect - 10 initial at
> 1972 plus 22 decreed inserts.

OK, so apply that same reasoning to dates before 1972, when UTC had
subsecond leaps and rate changes. Why not say that during this period the
NTP timescale (had it existed) would also have had subsecond leaps and
rate changes, communicated separately from the timestamps like leapseconds
are now?

A fixed 10s offset is obviously wrong because there is a fixed offset
between POSIX and NTP timestamps (except during leap seconds), so there is
a POSIX-like fixed mapping from wall clock time to NTP timestamps. (By
"wall clock time" I mean UT of whichever variety was in use at that time.)
So at the point in time where TAI was established, when it coincided with
UT, the NTP leap second count has to be 0.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

From clive at davros.org  Thu Aug 28 10:10:12 2014
From: clive at davros.org (Clive D.W. Feather)
Date: Thu, 28 Aug 2014 15:10:12 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <53FCB130.7090202@edlmax.com>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
Message-ID: <20140828141012.GD76389@davros.org>

Brooks Harris said:
> In particular, 8601 implies use of "offset 
> from UTC", as indication of "local time", but conflates this with 
> Daylight Savings.

No, it doesn't.

It uses offset from UTC as an indication of, wait for it, offset from UTC.

> For example, a date and time in New York City might be 
> represented as 2014-07-04T00:00:00-05:00 which misses the fact that 
> Daylight was in effect, or 2014-07-04T00:00:00-04:00 which misses the 
> fact the the fixed timezone offset is -05:00.

No.

2014-07-04T00:00:00-05:00 means the start of the day according to a clock
observing an offset of -5 hours. Someone in New York City might have such a
clock if they needed to correspond with Chicago.

2014-07-04T00:00:00-04:00 means the start of the day according to a clock
observing an offset of -5 hours. That is the offset typically observed [1]
in New York City on that date.

The use of an offset does *NOT* imply either a time zone or the presence or
absence of an bi-annual shift.

My office in Cambridge has clocks on the wall showing the time in offsets
-07:00, -04:00, +01:00, +02:00, +05:30, and +08:00, because those are the
ones we regularly communicate. Though they all show different numbers, they
are all showing the same time.

[1] But see R.v Haddock [1967] BBC 1.4.

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

From dot at dotat.at  Thu Aug 28 10:17:49 2014
From: dot at dotat.at (Tony Finch)
Date: Thu, 28 Aug 2014 15:17:49 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <1423.1409227810@critter.freebsd.dk>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
 <alpine.LSU.2.00.1408271650570.23119@hermes-1.csi.cam.ac.uk>
 <6801.1409161092@critter.freebsd.dk>
 <alpine.LSU.2.00.1408281021260.23119@hermes-1.csi.cam.ac.uk>
 <1423.1409227810@critter.freebsd.dk>
Message-ID: <alpine.LSU.2.00.1408281501000.29365@hermes-1.csi.cam.ac.uk>

Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> >However for events in the future (meetings etc.) you need to record a
> >time and a place, because the UTC offset and time zone rules are not
> >predictable.
>
> The main problem here is to get people to give you enough information
> in the first place.
>
> For instance:
>
> I add a meeting to my calendar at 10:00 day after tomorrow.
>
> Tomorrow I fly to Ulan Batoor.
>
> When is the meeting ?
>
> It could be a meeting in Ulan Batoor, it could be a phone-meeting
> back in Denmark or it could be a teleconference with Melbourne.
>
> Many heuristic attempts have been made to "DWIM" and all fails.

The meeting organizer has to specify a (single) place.

In many cases (like teleconferences) you will want to add secondary
locations to the details of the meeting. These locations don't affect the
time of the meeting (if timezone changes occur) but they are useful for
displaying the local times of the meeting for the remote participants, and
useful for the organizer to see if the proposed time is reasonable for
eveyone who needs to participate. And if timezone changes occur it's easy
to find the meetings which might be affected, i.e. the ones with multiple
locations not all of which are affected by the change, which is exactly
the ones that require human attention.

(Compare that last situation with Microsoft Exchange, which fixes the UTC
offset of a meeting at the time it is organized - or at least it did in
2007 when the North American DST rules changed. Exchange admins had to run
a special tool to adjust the times of all future meetings in North
America.)

Another interesting case is a meeting on a plane where the choice of
location is not clear. But if you specify "departing from X" or "arriving
at Y" it becomes clear which time zone to use and when you are planning to
adjust your clocks from X time to Y time.

No need for DWIM guessing games.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

From clive at davros.org  Thu Aug 28 10:26:51 2014
From: clive at davros.org (Clive D.W. Feather)
Date: Thu, 28 Aug 2014 15:26:51 +0100
Subject: [LEAPSECS] Leap second relationship to ISO 8601
In-Reply-To: <53FDE296.9070901@edlmax.com>
References: <000c01cfbfef$a1b8de50$e52a9af0$@comcast.net>
 <53FCB130.7090202@edlmax.com>
 <alpine.LSU.2.00.1408271011340.23119@hermes-1.csi.cam.ac.uk>
 <53FDE296.9070901@edlmax.com>
Message-ID: <20140828142651.GE76389@davros.org>

Brooks Harris said:
>> ISO 8601 does not represent daylight saving nor time zones.
> It can represent both, but incompletely, or ambiguously. The "time 
> element" called "zone designator" conflates "offset from UTC" and 
> "Daylight Savings offset" in the "time element" called "zone designator".

No. Its "zone designator" is actually offset from UTC. This is because it
is using a different meaning for the term "zone" than the TZ list does.

Compare the "military time zones". Without physically moving, for part of
the year I am in "zone" Zulu and for part of the year I am in "zone" Alpha.
That's their definition of "time zone". The TZ list would say that, at all
times, I am in "zone" Europe/London.

> Incorrect where? 2014-07-04T00:00:00-05:00 would have been correct in 
> Chicago. We only know this because we know a-priori Daylight Savings was 
> in effect in that jurisdiction.

No. Because we know that Chicago was using offset UTC-5 at the time.

> It was 2014-07-04T00:00:00-06:00 
> "Mountain Daylight Time" while it was 2014-07-04T00:00:00-07:00 in 
> Arizona, which does not observe Daylight Savings.

But note that these are *DIFFERENT* times. That one happened an hour after
the other one.

> Strictly from the 8601 representation we don't know if Daylight was in 
> effect or even if it is observed in the jurisdiction, so we can't 
> distinguish the "fixed offset from UTC to the local jurisdiction".

I've just looked at ISO 8601:2004 and can't find this phrase at all. What I
*do* find is:

2.1.14
standard time
time scale derived from coordinated universal time, UTC, by a time shift
established in a given location by the competent authority
[IEC 60050-111]
NOTE This time shift may be varied in the course of a year.

It is made clear in 4.2.5.1 and 4.2.5.2 that the offset notation shows
"the difference between the time scale of local time and UTC", and nothing
else. It is also noted in 4.2.2.1 that "no provisions have been made to
prevent ambiguities in expressions that result from discontinuities in the
time scale of local time (e.g. daylight saving time).".

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