Re: [LEAPSECS] leap minute or hour

[Warner Losh]

On Fri, Nov 18, 2022 at 9:34 PM Zefram via LEAPSECS 
wrote:

> Eric Scace wrote:
> >   This is much easier to deal with than writing code for future leap
> >   second changes on dates yet to be established/promulgated.
>
> It does ameliorate the problem of distribution of the leap schedule,
> but that benefit is not at all specific to the leap minute/hour system.
> The distribution is made easier by having a twenty year lead time on
> scheduling, and this feature of the system is not at all dependent on
> the nature of the schedule.  We have previously noted that there would be
> value in a multi-year lead time in scheduling leap seconds of the current
> form (individual leap seconds, making an effort to minimise |UT1-UTC|).
>
> If the intention is for UTC to track UT1 over the long term, even if it
> has a much greater tracking bound than previously, then we need to be
> prepared to handle leaps.  In this context, there is a major disadvantage
> to the leap minute/hour proposals, and even to just embargoing leap
> seconds for a century: they would result in needing to handle a leap
> when no one has experienced a leap for decades.  What are the chances
> of getting that right?  If we're going to have leaps at all, it seems
> better to keep leaps reasonably frequent, and even to insert gratuitous
> leaps to make them more frequent than at present (see the "leap second
> every month" proposal).  This way we would have a fair chance of making
> the leap-handling systems actually work.
>
> The CGPM resolution is, of course, taking the opposite approach,
> reasoning that leap seconds are just too hard to get right.  This seems
> a poor justification for abolishing a mechanism that's good for
> some applications, but if taken at face value it's even worse as a
> justification for any mechanism that would have very infrequent leaps.
> Leap seconds every couple of years are hard, true, but leaps once a
> century would be far harder to get right.  As has been previously noted
> in respect of the leap hour proposal, the CGPM resolution really looks
> like an attempt to abolish leaps entirely (which is what its rationale
> really justifies) without actually admitting that that is the aim.
> This is especially so with the proposal being so vague about what it
> intends to happen to UTC after the leapless century.
>
> The resolution has a note about TAI being insufficiently accessible to
> serve the technical purposes that require a completely regular time
> scale.  This seems like the thing to work on.  We ought to be making
> time distribution systems offer both TAI and UTC, with TAI as the more
> fundamental product and UTC explicitly layered on top of it.  That way
> the problems of leap seconds can be confined to those applications that
> actually want the UT1 tracking.  It's a lot of work, but we actually
> need to disseminate two or more time scales anyway, and it's preferable
> to do that in a well-specified way.
>

Alternatively, why does | UTC - UT1 | need to be bounded?  If we let it
accumulate
to an arbitrary level, and distributed UTC - UT1 to anybody that needed it,
then
that would accomplish the same thing that adding leap seconds does now,
without
the approximation that UTC ~ UT1. All applications that care updated to use
this value
could even have a higher level of performance without the need to hope that
the UTC
approximation is 'good enough'. This completely eliminates leap seconds
from timekeeping
while putting the onus on the applications that care to pay the freight
while removing
the leap second tax from the 99.99% of applications that don't care.

Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Zefram via LEAPSECS]

Eric Scace wrote:
>   This is much easier to deal with than writing code for future leap
>   second changes on dates yet to be established/promulgated.

It does ameliorate the problem of distribution of the leap schedule,
but that benefit is not at all specific to the leap minute/hour system.
The distribution is made easier by having a twenty year lead time on
scheduling, and this feature of the system is not at all dependent on
the nature of the schedule.  We have previously noted that there would be
value in a multi-year lead time in scheduling leap seconds of the current
form (individual leap seconds, making an effort to minimise |UT1-UTC|).

If the intention is for UTC to track UT1 over the long term, even if it
has a much greater tracking bound than previously, then we need to be
prepared to handle leaps.  In this context, there is a major disadvantage
to the leap minute/hour proposals, and even to just embargoing leap
seconds for a century: they would result in needing to handle a leap
when no one has experienced a leap for decades.  What are the chances
of getting that right?  If we're going to have leaps at all, it seems
better to keep leaps reasonably frequent, and even to insert gratuitous
leaps to make them more frequent than at present (see the "leap second
every month" proposal).  This way we would have a fair chance of making
the leap-handling systems actually work.

The CGPM resolution is, of course, taking the opposite approach,
reasoning that leap seconds are just too hard to get right.  This seems
a poor justification for abolishing a mechanism that's good for
some applications, but if taken at face value it's even worse as a
justification for any mechanism that would have very infrequent leaps.
Leap seconds every couple of years are hard, true, but leaps once a
century would be far harder to get right.  As has been previously noted
in respect of the leap hour proposal, the CGPM resolution really looks
like an attempt to abolish leaps entirely (which is what its rationale
really justifies) without actually admitting that that is the aim.
This is especially so with the proposal being so vague about what it
intends to happen to UTC after the leapless century.

The resolution has a note about TAI being insufficiently accessible to
serve the technical purposes that require a completely regular time
scale.  This seems like the thing to work on.  We ought to be making
time distribution systems offer both TAI and UTC, with TAI as the more
fundamental product and UTC explicitly layered on top of it.  That way
the problems of leap seconds can be confined to those applications that
actually want the UT1 tracking.  It's a lot of work, but we actually
need to disseminate two or more time scales anyway, and it's preferable
to do that in a well-specified way.

-zefram
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[jimlux]

On 11/15/22 1:34 PM, Poul-Henning Kamp wrote:


Demetrios Matsakis via LEAPSECS writes:


Another one, about traffic accidents, showed a whole bunch of wiggles =
over a year, and said that one of those coincided with a DST switch.


That one is actually pretty well documented in Europe, but most of the
extra accidents are wildlife-strikes.

Transpires that wildlife adapts to our rythm of life, but do not get the
memo that tomorrow rush-hour will be one hour different.



The contrary argument is for little kids out trick or treating on Oct 
31. DST means it's not as dark at 7PM-ish.



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Poul-Henning Kamp]

Demetrios Matsakis via LEAPSECS writes:

> Another one, about traffic accidents, showed a whole bunch of wiggles =
> over a year, and said that one of those coincided with a DST switch.

That one is actually pretty well documented in Europe, but most of the
extra accidents are wildlife-strikes.

Transpires that wildlife adapts to our rythm of life, but do not get the
memo that tomorrow rush-hour will be one hour different.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Demetrios Matsakis via LEAPSECS]

That evolutionary approach sounds like exactly what I think would happen if 
future leap seconds were abolished.  Over the centuries, and very gradually (as 
in not abruptly), people will on the average start going to work a little later 
as judged by the clock… if they even do “go to work” so far in the future.

On DST, maybe Tom should start a list serve devoted to it.  I believe one 
reason the House of Representatives did not take up the Senate bill was because 
some professional psychiatrist organizations have decided DST is horrible and 
they deluged the poor congresspeople with letters.  I like to make fun of one 
refereed publication that claims those Indiana students who were “subjected” to 
DST had a 16% lower IQ.  Another one, about traffic accidents, showed a whole 
bunch of wiggles over a year, and said that one of those coincided with a DST 
switch.  I also saw something associated with Fox News that had a few things 
just as strange as what people say about other things they propagate.  
Hopefully the shrinks have a more realistic publication base to draw from.

> On Nov 15, 2022, at 9:23 AM, Gerard Ashton via LEAPSECS 
>  wrote:
> 
> The bill currently in the US Congress, the "Sunshine Protection Act" (S. 623) 
> illustrates the desire of politicians to wait for decades to address an 
> issue, and then go for the quick fix. The bill would establish permanent 
> daylight saving time. The slower approach would be to abolish daylight saving 
> time and let people work out a schedule they decide is the best compromise 
> between summer and winter.
> 
> Gerard Ashton
> 
> On Tue, Nov 15, 2022 at 5:27 AM Poul-Henning Kamp  > wrote:
> 
> Clive D.W. Feather writes:
> 
> > Stick with what people are used to, which is (mostly) shifts of an hour.
> 
> Yeah, well...
> 
> That's the disadvantage of handling it at the political level:
> 
> There is no discernible upper limit to how stupid politicians can be about 
> timezones.
> 
> Apart from 15 minute and 30 minute deltas, there is a clear tendency to make 
> changes with far too short notice.
> 
> The good news is that stupid timezone decisions can only hurt the
> geographical area controlled by the politicians, so there is a
> feedback-mechanism in place.
> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com 
> https://pairlist6.pair.net/mailman/listinfo/leapsecs 
> 
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Steffen Nurpmeso]

Miroslav Lichvar wrote in
 :
 |On Mon, Nov 14, 2022 at 09:22:27PM +, Poul-Henning Kamp wrote:
 |> Full hour shifts, on the other hand, can be done merely by changing
 |> the time-zone, and they can be done through the normal political
 |> process, aligned to recognized borders.
 |
 |It doesn't even have to be a full-hour shift. Some countries use
 |timezones with offsets given in 15-minute resolution, so any software
 |used globally already has to support 15-minute shifts. Adding support
 |for 1-minute shifts in timezones might be easier than Y2K.

So just to point out as i did on some IETF list also that the IANA
TZ even introduced a mechanism to support sub-second precision.
All this is solely political, and it is nothing but politeness and
also (a bit, or two) desire to integrate in the western
(-originated) technology (domination (colonialism)) that keeps
timezones in this scheme.

But if China for example would change to _real_ Shangai time
instead of the mutilated western-compatible variant, then suddenly
~1.4 billion people would be off, and for example the email
standard could not cope with it because the Date: header does not
have second resolution for timezones, and it seems the IETF is
currently cementing this fact in a revision of RFC 3339 if i got
that right.  This is, imho western biased focus, sheer ignorance,
or maybe only what PHK has in his email footer for decades.
Does not matter in that run down aggressive dishonest western lead
world of pseudo moral with much more to be said but all off-topic,
but would be an indication of mutual respect and politeness.

 |I guess a bigger issue with existing software, if for some reason it
 |couldn't be updated anymore, would be the maximum offset that can be
 |accepted or represented. There might be a sanity check requiring
 |the offset to be smaller than 24 hours as the current maximum is 14
 |hours. The ISO 8601 format has only two digits for hours in the UTC
 |offset, so that wouldn't work for longer than a million years.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Gerard Ashton via LEAPSECS]

The bill currently in the US Congress, the "Sunshine Protection Act"
(S. 623) illustrates the desire of politicians to wait for decades to
address an issue, and then go for the quick fix. The bill would establish
permanent daylight saving time. The slower approach would be to abolish
daylight saving time and let people work out a schedule they decide is the
best compromise between summer and winter.

Gerard Ashton

On Tue, Nov 15, 2022 at 5:27 AM Poul-Henning Kamp 
wrote:

> 
> Clive D.W. Feather writes:
>
> > Stick with what people are used to, which is (mostly) shifts of an hour.
>
> Yeah, well...
>
> That's the disadvantage of handling it at the political level:
>
> There is no discernible upper limit to how stupid politicians can be about
> timezones.
>
> Apart from 15 minute and 30 minute deltas, there is a clear tendency to
> make changes with far too short notice.
>
> The good news is that stupid timezone decisions can only hurt the
> geographical area controlled by the politicians, so there is a
> feedback-mechanism in place.
>
> --
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Poul-Henning Kamp]

Clive D.W. Feather writes:

> Stick with what people are used to, which is (mostly) shifts of an hour.

Yeah, well...

That's the disadvantage of handling it at the political level:

There is no discernible upper limit to how stupid politicians can be about 
timezones.

Apart from 15 minute and 30 minute deltas, there is a clear tendency to make 
changes with far too short notice.

The good news is that stupid timezone decisions can only hurt the
geographical area controlled by the politicians, so there is a
feedback-mechanism in place.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Clive D.W. Feather]

Miroslav Lichvar said:
> It doesn't even have to be a full-hour shift. Some countries use
> timezones with offsets given in 15-minute resolution,

True, though they're very rare.

> so any software
> used globally already has to support 15-minute shifts. Adding support
> for 1-minute shifts in timezones might be easier than Y2K.

I don't see the benefit of anything less than the current 15 minutes.
People all round the world are used to clock and solar time differing by
more than that (I think the record is about 3 hours), so why make things
awkward for people? Stick with what people are used to, which is (mostly)
shifts of an hour.

-- 
Clive D.W. Feather  | If you lie to the compiler,
Email: cl...@davros.org | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Miroslav Lichvar]

On Mon, Nov 14, 2022 at 09:22:27PM +, Poul-Henning Kamp wrote:
> Full hour shifts, on the other hand, can be done merely by changing
> the time-zone, and they can be done through the normal political
> process, aligned to recognized borders.

It doesn't even have to be a full-hour shift. Some countries use
timezones with offsets given in 15-minute resolution, so any software
used globally already has to support 15-minute shifts. Adding support
for 1-minute shifts in timezones might be easier than Y2K.

I guess a bigger issue with existing software, if for some reason it
couldn't be updated anymore, would be the maximum offset that can be
accepted or represented. There might be a sanity check requiring
the offset to be smaller than 24 hours as the current maximum is 14
hours. The ISO 8601 format has only two digits for hours in the UTC
offset, so that wouldn't work for longer than a million years.

-- 
Miroslav Lichvar

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Poul-Henning Kamp]

Steve Allen writes:
> On Mon 2022-11-14T21:22:27+ Poul-Henning Kamp hath writ:
> > I doubt the will manage to convince the other 99+% to do something
> > as deranged as a leap-minute.
>
> > Thanks to timezones and DST, less than 1% of the worlds population
> > live where mean solar time is correct to a minute.
>
> The reason we got leap seconds in the first place is that one country
> changed its law so that the rubber/elastic seconds of original UTC
> became illegal.

Steve please drop the conspiracy theories.

We got leap-seconds because a second of variable duration was useless
for several rapidly developing technologies, from atoms to space
via the laser and digital telecom.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Clive D.W. Feather]

Poul-Henning Kamp said:
> Full hour shifts, on the other hand, can be done merely by changing
> the time-zone, and they can be done through the normal political
> process, aligned to recognized borders.

Something I've been arguing for a long time.

-- 
Clive D.W. Feather  | If you lie to the compiler,
Email: cl...@davros.org | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Steve Allen]

On Mon 2022-11-14T21:22:27+ Poul-Henning Kamp hath writ:
> I doubt the will manage to convince the other 99+% to do something
> as deranged as a leap-minute.

> Thanks to timezones and DST, less than 1% of the worlds population
> live where mean solar time is correct to a minute.

The reason we got leap seconds in the first place is that one country
changed its law so that the rubber/elastic seconds of original UTC
became illegal.  Even though they were advised of serious technical
problems the other countries capitulated to leap seconds as the
"parfaitement recommandable" solution to the political problem.
We do not have Hari Seldon theory to guage the psychohistory of
international alliances and how they will align with each other about
answering "What time is it?"

--
Steve Allen  WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064   https://www.ucolick.org/~sla/  Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Steffen Nurpmeso]

Poul-Henning Kamp wrote in
 <202211142122.2aelmriv024...@critter.freebsd.dk>:
 |
 |Eric Scace writes:
 |
 |> If a leap minute were to be added/removed at some future date
 |> when UTC became significantly more that 30 seconds different from
 |> mean solar time, [...]
 |
 |Thanks to timezones and DST, less than 1% of the worlds population
 |live where mean solar time is correct to a minute.
 |
 |I doubt the will manage to convince the other 99+% to do something
 |as deranged as a leap-minute.
 |
 |Full hour shifts, on the other hand, can be done merely by changing
 |the time-zone, and they can be done through the normal political
 |process, aligned to recognized borders.

Heck.  As long as we all come together at the right time in
Stonehenge, everything is all right!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Poul-Henning Kamp]

Eric Scace writes:

> If a leap minute were to be added/removed at some future date
> when UTC became significantly more that 30 seconds different from
> mean solar time, [...]

Thanks to timezones and DST, less than 1% of the worlds population
live where mean solar time is correct to a minute.

I doubt the will manage to convince the other 99+% to do something
as deranged as a leap-minute.

Full hour shifts, on the other hand, can be done merely by changing
the time-zone, and they can be done through the normal political
process, aligned to recognized borders.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Steffen Nurpmeso]

Eric Scace wrote in
 <210d4e22-f86b-4ebe-b6ea-fe6b4fbff...@scace.org>:
 |   If a leap minute were to be added/removed at some future date when \
 |   UTC became significantly more that 30 seconds different from mean \
 |   solar time, many years could be made available (e.g., 20 years!) \
 |   to retire/replace/rewrite software for such an unusual event whose \
 |   occurrence is on a KNOWN date/time in the future.
 |
 |   This is much easier to deal with than writing code for future leap \
 |   second changes on dates yet to be established/promulgated.
 |
 |   As an example, if the delta was wandering around 40 seconds, BIPM \
 |   could announce a leap minute to occur twenty years from the date \
 |   of the announcement… and, if a sense of humor existed, put it on \
 |   Feb 29th of a leap year.

On the road of changing civil human time for the benefit of
machines lies madness.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] leap minute or hour

[Eric Scace]

   If a leap minute were to be added/removed at some future date when UTC 
became significantly more that 30 seconds different from mean solar time, many 
years could be made available (e.g., 20 years!) to retire/replace/rewrite 
software for such an unusual event whose occurrence is on a KNOWN date/time in 
the future.

   This is much easier to deal with than writing code for future leap second 
changes on dates yet to be established/promulgated.

   As an example, if the delta was wandering around 40 seconds, BIPM could 
announce a leap minute to occur twenty years from the date of the announcement… 
and, if a sense of humor existed, put it on Feb 29th of a leap year.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs