[LEAPSECS] The definition of a day

Rob Seaman seaman at noao.edu
Fri Jan 30 08:21:42 EST 2015

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.

More information about the LEAPSECS mailing list