[LEAPSECS] The definition of a day
imp at bsdimp.com
Fri Jan 30 10:41:55 EST 2015
Rob loves to quote the archives as if they irrefutably prove his point. They don’t.
They just point to the various discussions we’ve gone round and round on. Nobody
has made a decisive argument on either side, and few minds have changed.
The biggest thing that’s ignored in them is that time zone can and do change
all the time. Dozens of changes are pushed to the time zone files many times
a year. Each little change isn’t a big deal. Heck the US even changed its DST
rules a few years ago and people coped. A few devices with hard-coded DST
broke, and OSes that weren’t updated in time were a problem. Not the kind
of thing you want to do all the time, but the disruption was small enough
that it could be done on a scale of decades easily enough. From time to
time there’s even tweaks to the boundaries of the time zones. Kentucky and
Indiana have tweaked the most, but there’s other odd adjustments as populations
shift and patterns of trade follow. The scale one would need to adjust by an
hour is measured quite literally in centuries (or multiple centuries) for the
next few thousand years. It fits well with the micro tweaks going gone all the
time. Some locations want to do DST, others don’t, others think having their
clocks an hour earlier or later would be a good thing.
Apologists for keeping leap seconds ignore this argument. Partially because
it wasn’t made in the official proposals that never went anywhere. Partially
because they like to argue against the leap hour in UTC which was stupidly
suggested in the official proposals. Partially because there’s not a good answer
to this point (there are good answers to other points, but if synchronization to
the earth is important for the masses, this is a perfectly valid way to achieve
that which won’t cause any confusion at all given the time-scales involved).
Now, there are technical users of UTC that do care very much about an error
of even a second. Not because it makes their mornings or afternoons longer,
but because they view UTC as a measure of the earth’s angle and need to
point something in that direction. This is not an unreasonable thing to assume
today, since UTC is approximately that by definition. Changes to that definition
would cause real difficulties for these people.
As for the ‘UTC doesn’t match local time’ it already doesn’t. It kinda matches
it to a good approximation, but that approximation is arbitrary. Why 1s? Why
not .1s or 10s? There are reasons, some of them good some of them bad.
But if I needed to know the local, solar time, you’d simply use the UT1 - UTC[new]
tables we’re already producing to do that. On the scale of decades, you’d
have one minute accuracy with a single number. This is considerably more
stable than local time zone observation, especially on the edges of the
time zones. The “leap hour historical table” boogie man isn’t such a big
deal because we already have him. The Olson timezone database already
encodes this, even for the whacked out case where you have two people
living in the same area that are on different time zones (Israelis and
Palestinians in the west bank). Adding entries to this on a scale of centuries
will be so far in the noise that I can’t believe it is a problem.
> On Jan 30, 2015, at 9:00 AM, Alex Currant via LEAPSECS <leapsecs at leapsecond.com> wrote:
> Do the archives also have emails calling this is a scare-tactic? Are there emails saying that society will shift naturally and imperceptibly, so that no one will ever have to go to work or school in the dark? Right now schools are talking about shifting their hours so that grade-school kids will go early and high school kids will go late. Nobody is arguing that it will disrupt the American nation. Aren't we confusing time with the measurement of time? Is that as bad as confusing perfect programming with real-world programmers?
> Is it also playing into fears to do the math poorly about the effect in the short run? Does anybody really think there will average almost a leap second a year between now and 2100, so that the new predictions are wrong? I checked the numbers. Less than a minute by 2100. Is this why those against the ITU resolution don't acknowledge them?
> From: Rob Seaman <seaman at noao.edu>
> To: Leap Second Discussion List <leapsecs at leapsecond.com>
> Sent: Friday, January 30, 2015 8:21 AM
> Subject: Re: [LEAPSECS] The definition of a day
> Again, these topics are well covered in the archives. By all means talk about them more, but it would be appropriate to include the top post(s) of prior thread(s) when restarting a topic.
> To summarize some previous talking points: Only a small fraction of the world observes daylight saving time of any sort. Those that do remain relatively closely synchronized in their seasonal adjustments with others in the same hemisphere. When the powers-that-be currently monkey around with the time zones they make only small bounded offsets. But this would introduce monotonically growing and quadratically accelerating unbounded changes with no synchronization. Coordination of local time would be abandoned altogether. Future adjustments would differ by years, decades or centuries from neighboring countries. They would be unpredictable in advance and impossible to keep straight after the fact. Large countries would splinter. Record keeping for historical, scientific, economic purposes would suffer.
> The underlying timescale (redefined-UTC) would retain no connection to local time. Instead of a simple offset (Arizona is UTC - 7 hours), there wouldn't even be a coherent algorithm to recover one from the other. Computer localization would become a nightmare.
> Instead of a small table of worldwide leap seconds, a huge database of localized historical leap hour shifts would be needed to recover interval timing or timestamps. This DB would be riddled with errors. Different libraries, applications, and operating systems would have different errors. It would be all the difficulties maintaining the IANA tz database, but on steroids.
> The zero point of the timezone system would be lost. There is no process in place (if UTC doesn't remain equivalent to GMT) to either keep the prime meridian and international date line fixed - or alternately to permit them to move at a faster and faster pace.
> If this were an actual plan the implications should be worked out in advance. Well known systems engineering best practices should be applied. Trade-offs in cost, schedule, performance and risks should be explored for different use case scenarios across the range of stakeholders.
> Rather this has always just been suggested with a "see how easy this is?" It isn't easy and the cure would be orders-of-magnitude worse than the complaint.
> And why beholdest thou the mote that is in thy brother's eye,
> but considerest not the beam that is in thine own eye?
> > On Jan 30, 2015, at 3:34 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
> >> So, let us suppose the year 2600 is when the drift reaches the annoying
> >> point, and let us suppose the EU is still in existence. By then the sun will
> >> reach its highest point at about 12:45 UTC. So at this point the EU
> >> announces (a few years ahead) that the normal autumn shift back of the
> >> clocks will not happen. ...
> >> Dealing with local time changes as you cross borders is something people are
> >> used to, as is the fact that the amount of change varies both within the
> >> year and from year to year. So there's nothing new for people to get used
> >> to.
> > It's not as simple as just skip an hour shift.
> > I'm in the US. We are used to dealing with hour shifts in the spring/fall.
> > But the system has had years to get used to that. If you skip one, then all
> > sorts of things need to get adjusted. I'm thinking of things like schools
> > starting in daylight so there are fewer traffic accidents. It doesn't matter
> > if they start at 8AM or 9AM or 7AM, but if they have been starting at 8AM and
> > you adjust the clocks by an hour you need to adjust the starting time by an
> > hour to get back to where you want to be.
> > It would be an interesting exercise to collect all the issues like that.
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
More information about the LEAPSECS