On Fri, Jun 20, 2003 at 01:45:03PM -0700, John Meacham wrote:
On Fri, Jun 20, 2003 at 07:36:23PM +0200, Dylan Thurston wrote:
Should there also be a function to get offsets (in seconds) between UTC and TAI?
On reflection, I think this is too precise information to be accessible from a portable library. In particular, I'm not sure it's possible to correctly implement a TAI-based time system on most Linux distributions without modification (I was rather shocked to discover this...), and I'm sure there are some desired platforms for Haskell which make it very hard to implement that. So the standard should _allow_ for correct implementations, but not _require_ it.
yeah. it is expected that many systems will not be able to fully conform to this standard. but getting pretty close is good enough for most applications, however we need to actually give the standard routines defined semantics if they are to be useful. At least by defining ClockTime in terms of TAI we can actually use the value to represent real times in the future and past and perform arithmetic on it that makes sense, this is quite useful functionality in general, imagine an accounting program that reads in a bunch of times, performs some operations on them and spits the times back out into another file, the fact that the system doesn't quite conform DOESN'T matter because we are never actually using the systems time functionality. Not concretly specifying what ClockTime means because not all systems have a concrete definition of their own time would be foolish, lots of applications don't need to access the current time yet want to work with dates and times. On Sat, Jun 21, 2003 at 12:59:27AM +0200, Dylan Thurston wrote: there are lots of third party libraries which provide this functionality, they are vital for many types of scientific computing. it is quite plausable that a haskell implementation might use such a library if it finds it. This is not just for current implementations but a proposal for inclusion in Haskell proper. (I wish we could consider the current Time library a big typo and retroactivly change haskell 98..) Any explicitly undefined or implementation dependent behavior will be a source of problems, by giving a precise if not always obtainable definition we can at least guarentee that all implementations are shooting for the same goal..
yes. this would solve another problem I mentioned in a different email about the user implementing their own time types and needing the raw leap second info. perhaps:
leapSeconds :: ClockTime -> Int ...
That's probably too precise: perhaps the implementation has no access to raw leap seconds, or perhaps the standard changes and the offset is no longer an integer number of seconds.
if the implementation doesn't have access to raw leap seconds then an embedded table could be used as a heuristic. This functionality is mainly just useful for people that want to look at what Haskell is using internally as I could see situations when it would be useful. Most systems fudge this anyway, at least in Haskell we will be providing a way to see exactly how the implementation is fudging it :) Think of it as not 'what are the leap seconds' but 'what do you think the leap seconds are?' John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------