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