System.Time.Clock Design Issues

[Graham Klyne]

I would support both of these positions.

But I just noticed Simon M's response, and wonder if I'm missing something 
here:
[[
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)?

#g
--

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
>type?
>
>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:
http://www.ninebynine.org/#Contact