Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Clive D.W. Feather
M. Warner Losh said:
 time_t is so totally broken, it isn't funny.  That's the closest thing
 to a standardized API there is for time.  All others are stuff folks
 have done here or there, but they aren't universal enough to be
 considered.

 Too bad the problems with time_t are well known, well discussed and
 well enumerated.  Or rather I should say too bad POSIX doesn't care
 enough to change it since the cost of changing time_t is huge...

Not so.

POSIX in the past deferred to WG14 (the ISO C committee) because that's
where time_t came from.

WG14 is willing in principle to make changes to time_t, up to and including
completely replacing it by something else. *BUT* it needs a complete and
consistent proposal and, preferably, experience with it.

Any proposal has got to deal with a whole load of issues, many of which
haven't been properly documented. For example, it should be possible to add
and subtract times and intervals (e.g. what time is 14 months and 87 days
from now?).

--
Clive D.W. Feather  | Work:  [EMAIL PROTECTED]   | Tel:+44 20 8495 6138
Internet Expert | Home:  [EMAIL PROTECTED]  | Fax:+44 870 051 9937
Demon Internet  | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc||


Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Ashley Yakeley

On Dec 26, 2006, at 23:02, M. Warner Losh wrote:


Of course, needing to know TAI-UTC offsets leads one to interesting
situations.  What does one do if one has TAI time, but not UTC and a
conversion is asked for?


If it's a time in the future rather than just the current time, the
thread may have to block for years...

Probably you'd want a quick function that returns a special don't
know value, or throws exception, or returns a special result code
(as COM). Then the caller can decide what to do.

--
Ashley Yakeley


Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Tony Finch
On Wed, 27 Dec 2006, Zefram wrote:

 Your principle is probably correct; I'm just saying that the
 implementation you're thinking of doesn't actually satisfy the criterion.

When you quoted me you snipped the bit where I said its implementation is
far from ideal. This is not just because of the update problem: the whole
library is built around time_t and the traditional time API both of which
are hopeless.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
NORTH UTSIRE SOUTH UTSIRE: WEST OR NORTHWEST 3 OR 4, OCCASIONALLY 5. SLIGHT.
FAIR. MODERATE OR GOOD.


Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Zefram writes:
Ashley Yakeley wrote:

In the Haskell time library, I represent UTC time by what seemed to
me the simplest possible correct type. This is a record containing an
integer to represent day number (as MJD), and a fixed-point decimal
(picosecond resolution) to represent seconds since midnight. The
allowed range for this is 0 to 86400..

That's a pretty good format.

That's a pretty bad format.  Computers are binary and having
pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec
and picoseconds in Haskell is both inefficient and stupid.

The fractional part should be a binary field, so that the width
can be adjusted to whatever precision and wordsize is relevant.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Rob Seaman

Clive D.W. Feather writes:


WG14 is willing in principle to make changes to time_t, up to and
including
completely replacing it by something else. *BUT* it needs a
complete and
consistent proposal and, preferably, experience with it.


This is at the heart of my distaste for the so-called leap hour
proposal.  There is no coherent proposal, no implementation plan, no
discussion of adverse effects, no budget, no collection of pertinent
use cases, no exploration of requirements - no technical design
discussion at all.

Meanwhile, the astronomical community (like other prudent
communities, presumably) has instituted long range planning efforts
like the U.S. Decadal Surveys.  Major (and minor) telescope and
instrumentation projects involve multi-year design commitments with
significant budgets of their own simply to develop coherent and
complete proposals to submit to the funding agencies.  The U.S.
national centers have recently been subject to an NSF Senior Review
process that is likely to have a major affect on all our operating
budgets to free up funding for new initiatives.  No pain, no gain.

On the other hand, we have a proposal to change the fundamental
underpinnings of world-wide civil timekeeping.  A (publicly
unavailable) proposal that can't even be bothered to suggest how DUT1
will be conveyed in a future in which this quantity would assume
vastly greater importance.  It's an embarrassment.


Any proposal has got to deal with a whole load of issues, many of
which
haven't been properly documented. For example, it should be
possible to add
and subtract times and intervals (e.g. what time is 14 months and
87 days
from now?).


Poul-Henning Kamp wrote:


... which is exactly the kind of thing you can not do with any
{origin+offset} format, due to leap seconds.


Leap seconds are an effect, not a cause.  The intrinsic difficulty is
with mapping interval time to Earth orientation (mean solar time).
Whatever mechanism is used to synchronize civil time to the sun -
including embargoing leap seconds as leap hours - there will always
be this complication.

Consider an ISO 8601 compliant date/time representation, e.g.:

   % date -u +%FT%TZ
   2006-12-27T16:47:27Z

The first part is the (Gregorian) calendar date - the second clearly
represents a fraction of a day.  From my point of view, this is the
beginning and end of the argument establishing an identity between
civil time and mean solar time.  Others are willing to permit a slow
secular drift - in the calendar, too, of course, not just in the
clock.  Mucking with leap seconds is equivalent to redefining the
concept of a day.

The point is that over a long enough period, a broad enough temporal
horizon, we all agree that civil time must be synchronized to solar
time.  The emergence of the absurd leap hour proposal from among
folks who loathe leaps of any sort demonstrates that.  They weren't
eager to center their notional position around leap hours - rather,
they felt obligated.  In short, there is no escaping the need to
grapple with the fundamental distinction between Earth orientation
and atomic interval counts.  Just as, as one enlarges ones spatial
horizon one cannot fail to run into relativistic effects.

Timekeeping is a subtle business.  Others on this list surely
understand that better than I.

Rob Seaman
NOAO


Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread John Cowan
Zefram scripsit:

 In the general case: to determine or use an interval of N calendar FOOs,
 it is convenient to represent the time as a linear count of calendar
 FOOs plus details of the exact position within the current FOO.  FOO may
 be minute, hour, day, week, month, or year.  I think there should be
 record formats for all of these cases (the native UTC format is one
 of these with FOO = day), with conversion functions between them and
 also a linear count of seconds.

That's overkill.  If we confine ourselves to the Gregorian calendar,
a time interval can be safely represented as a triple of months,
minutes, and seconds.  All time units longer than a month contain
a fixed and integral number of months, and all time units larger
than a minute and smaller than a month contain a fixed and integral
number of minutes.  (If we don't care about leap seconds, shock
horror, we can just use months and seconds.)

--
The man that wanders far[EMAIL PROTECTED]
from the walking tree   http://www.ccil.org/~cowan
--first line of a non-existent poem by: John Cowan


Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Ashley Yakeley

On Dec 27, 2006, at 06:29, Poul-Henning Kamp wrote:


That's a pretty bad format.  Computers are binary and having
pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec
and picoseconds in Haskell is both inefficient and stupid.

The fractional part should be a binary field, so that the width
can be adjusted to whatever precision and wordsize is relevant.


It's impossible to accurately represent a millisecond using binary
fractions. That would be unacceptable for most sub-second use.

A better idea might have been to use Haskell's Rational type for
the seconds offset, which is stored as two integers (for numerator
and denominator). Instead I used a fixed-point type (internally just
an integer from 0 to 86400). It does not separate
integer and decimal part.

--
Ashley Yakeley


Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Ashley Yakeley

On Dec 27, 2006, at 14:32, Poul-Henning Kamp wrote:


It's impossible to accurately represent a millisecond using binary
fractions. That would be unacceptable for most sub-second use.


Reality check: with a 32bit fraction, the error would be 69 ps.


...which accumulates in arithmetic and causes equality comparisons to
fail. This should hold:

   1000 * 1ms == 1s

It won't if you use a binary fraction.


A better idea might have been to use Haskell's Rational type for
the seconds offset, which is stored as two integers (for numerator
and denominator). Instead I used a fixed-point type (internally just
an integer from 0 to 86400). It does not separate
integer and decimal part.


Yes, let us make it as expensive as possible to operate on timestamps,
so that everybody will have to invent their own faster type.

NOT!


I'm not seeing the problem here: you can represent an integer in the
range 0 to 86400 with a 64-bit type. There's nothing
faster than integer arithmetic.

--
Ashley Yakeley


Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread John Cowan
Rob Seaman scripsit:

 Mucking with leap seconds is equivalent to redefining the
 concept of a day.

Very true.  And adopting the Egyptian-Roman calendar redefined
the concept of a month.  Somehow civilization survived.

--
John Cowan   [EMAIL PROTECTED]   http://ccil.org/~cowan
I must confess that I have very little notion of what [s. 4 of the British
Trade Marks Act, 1938] is intended to convey, and particularly the sentence
of 253 words, as I make them, which constitutes sub-section 1.  I doubt if
the entire statute book could be successfully searched for a sentence of
equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940


Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Daniel R. Tobias
On 27 Dec 2006 at 20:57, John Cowan wrote:

 Very true.  And adopting the Egyptian-Roman calendar redefined
 the concept of a month.  Somehow civilization survived.

Keeping months in sync with phases of the moon apparently turned out
to be insufficiently important to civilization to require it as a
feature of the calendar.  I'm doubtful that keeping clocks in
approximate sync with the rising and setting of the sun is likely to
be judged equally unimportant, however.

--
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/