System.Time.Clock Design Issues

Graham Klyne GK at
Thu Feb 3 05:13:49 EST 2005

I would support both of these positions.

But I just noticed Simon M's response, and wonder if I'm missing something 
I don't think we need this either, at lesat not in the external
interface.  Any calculations you can do with this type you can do on a
calendar time.
Is it proposed that the primary interface include a calendar time (which I 
take to mean something like (year,month,day,hour,min,sec,subsec)?


At 18:53 02/02/05 -0800, Ashley Yakeley wrote:
>* What resolution should we use, and should it be platform-dependent?
>My preference is (platform-independent) picoseconds to match the
>existing System.Time library and as a hedge against Moore's law.
>* Should we include a (days,ticks) UTC type separate from the POSIX time
>I have two reasons for wanting this. Firstly, correctness: the POSIX
>time type cannot represent leap seconds, whereas this can. Secondly,
>this holds the result of a useful function that splits POSIX time into
>the simplest possible date and time parts, which can then be used for
>converting to various internationalised calendars.

Graham Klyne
For email:

More information about the Libraries mailing list