Time library discussion (reprise)

Graham Klyne GK at ninebynine.org
Wed Nov 12 11:18:51 EST 2003

At 13:34 11/11/03 +0000, Simon Marlow wrote:
>Presumably, without TAI support, the library will be unable to do
>accurate calendar calculations at the second level (i.e. "add S seconds
>to time T"), although it will be able to do larger scale calendar
>calculations (i.e. adding days, months, etc.).  Or maybe you provide the
>second-level calculations but document that they don't take into account
>leap seconds?

When I raised this, I was thinking of something like:
... you provide the second-level calculations but document that they MAY 
not take into account leap seconds?

I found the reference posted by Peter Simons was helpful.

To my mind the stability of representation is more important than stability 
of operations.  Why?  In general I feel that representations have greater 
need of stability.  Specific values are written down, maybe find themselves 
embedded in code, while the results of operations are relatively transient 
(but this distinction may be contentious in the context of a pure 
functional language).

I noticed this in another of Peter's references:
This proposal makes no recommendations for handling leap seconds. Such 
capabilities are implementation­defined (just as they are in ISO C99). It 
does, however, allow implementations to support multiple calendric systems; 
thus an implementation could provide variations of its supported calendric 
systems that both do and do not handle leap seconds.
-- http://david.tribble.com/text/c0xcalendar.html#solutions

One other point:  Haskell has a significant advantageous difference to C 
when it comes to time representations of dates and times, viz its Integer 
type.  (I was persuaded by previous discussions that we should not be 
concerned for its efficiency.)


Graham Klyne
For email:

More information about the Libraries mailing list