Re: how do computer people want their time clocked?

From: Paul Eggert <eggert_at_twinsun.com>
Date: Wed, 30 May 2001 18:53:14 -0700 (PDT)

> Date: Wed, 30 May 2001 15:45:29 +0200
> From: "Deckers, Michael" <Michael.Deckers_at_FUJITSU-SIEMENS.COM>

> I also often hear similar arguments, and try to respond like this:

But people who want 86,400 seconds per day do not want to hear
complicated explanations as to why they're being sloppy. They just
want their applications to work without fuss. And they have a point.
Their basic problem is that the UTC timescale is not appropriate for
their applications. Their applications would work better with UTS.


> -- "By UTC convention, the adjustment happens at the end of a calendar day,
> just before midnight. Upon reaching 24:00:00 that day, UTC is set
> back by 1 s, effectively running again from 23:59:59 to 24:00:00."

Technically speaking this is incorrect. First, as you probably know,
the UTC markers are 23:59:59, 23:59:60, 00:00:00. Second -- and this
is a more subtle point -- UTC is set back immediately after an
inserted leap second, which means that if your clock has 86,400
seconds per day (as is required for POSIX applications, for example),
then it should tick 23:59:59, 00:00:00, 00:00:00. The POSIX clock is
not set back to 23:59:59; it is set back to 00:00:00.

It is this sort of confusion (even among experts!) that causes many
people to think that there must be a better way to handle civil time,
a way that does not involve discontinuities.


> It is from such dicussions that I got the impression that monotonicity
> is all they need.

For an example of why monontonicity does not suffice, please see
ISO/IEC 9945-1:1996 (POSIX 1003.1-1996), section 2.2.2.13, page 25,
lines 488-498. This standard formally defines a day to be 86,400
seconds. This assumption is not merely part of an international
standard: it is hardcoded into a lot of real-world software, including
some of the software that was used to deliver your message to this list.
Received on Wed May 30 2001 - 18:53:26 PDT

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT