| the haskell 98 time library is horribly broken, if you are using ghc, | you can deconstruct the time constructor which has an Integer containing | the number of seconds since epoch... otherwise you can use | ... | I dont supose this could be considered a typo in the haskell 98 report? | it is an embarasing thing for a language to not be able to do... Alas, no. CUP is, even as I type, printing the Haskell 98 Report. We'll have to think about how to accumulate further bugs/suggestions for H98. Meanwhile, I suspect there's an opportunity for someone (or a small group) to suggest a new Time library that really does the business, and provide an implementation. If it's sufficiently persuasive, all the implementations will adopt it and it can become a de-facto standard. The implementation is important because Time is a weird enough thing that only an expert can implement the spec! I think the current Time library suffered because no one who Really Cared about time was involved in its design or implementation. Simon
Simon Peyton-Jones (Mon, Feb 03, 2003 at 10:06:40AM -0000):
| the haskell 98 time library is horribly broken, if you are using ghc, | you can deconstruct the time constructor which has an Integer containing | the number of seconds since epoch... otherwise you can use | ... | I dont supose this could be considered a typo in the haskell 98 report? | it is an embarasing thing for a language to not be able to do...
Meanwhile, I suspect there's an opportunity for someone (or a small group) to suggest a new Time library that really does the business, and provide an implementation. If it's sufficiently persuasive, all the implementations will adopt it and it can become a de-facto standard.
A sound base for a Time implementation should use TAI (temps atomique international), c.f. <http://cr.yp.to/libtai.html>.
The implementation is important because Time is a weird enough thing that only an expert can implement the spec!
-- Stefan Karrmann
Stefan Karrmann <sk@mathematik.uni-ulm.de> writes:
A sound base for a Time implementation should use TAI (temps atomique international), c.f. <http://cr.yp.to/libtai.html>.
I disagree; I think UTC is quite sufficient, and will match the users' expectations much better. (executive summary: UTC is the time on your watch (+/- timezone of course), TAI is behind by a few seconds, and this difference changes each time there's a new leap second). However, the reference above is not to TAI, but to a library called libtai. I don't know anything about this; Stefan, maybe you could tell us some more? --KW 8-)
[Keith Wansbrough <Keith.Wansbrough@cl.cam.ac.uk>]
Stefan Karrmann <sk@mathematik.uni-ulm.de> writes:
A sound base for a Time implementation should use TAI (temps atomique international), c.f. <http://cr.yp.to/libtai.html>.
I disagree; I think UTC is quite sufficient, and will match the users' expectations much better. (executive summary: UTC is the time on your watch (+/- timezone of course), TAI is behind by a few seconds, and this difference changes each time there's a new leap second).
However, the reference above is not to TAI, but to a library called libtai. I don't know anything about this; Stefan, maybe you could tell us some more?
I know it's not really on topic, but for those of us who are ignorant of the details of time standards, does anyone have a pointer to a decent conceptual (i.e., non-software specific) overview of the subject? Leap seconds, etc., are all pretty much new to me, but I am curious. Matt -- Matt Hellige matt@immute.net http://matt.immute.net
On Thursday, February 6, 2003, at 12:47 PM, Matt Hellige wrote:
[Keith Wansbrough <Keith.Wansbrough@cl.cam.ac.uk>]
Stefan Karrmann <sk@mathematik.uni-ulm.de> writes:
A sound base for a Time implementation should use TAI (temps atomique international), c.f. <http://cr.yp.to/libtai.html>.
I disagree; I think UTC is quite sufficient, and will match the users' expectations much better. (executive summary: UTC is the time on your watch (+/- timezone of course), TAI is behind by a few seconds, and this difference changes each time there's a new leap second).
However, the reference above is not to TAI, but to a library called libtai. I don't know anything about this; Stefan, maybe you could tell us some more?
I know it's not really on topic, but for those of us who are ignorant of the details of time standards, does anyone have a pointer to a decent conceptual (i.e., non-software specific) overview of the subject? Leap seconds, etc., are all pretty much new to me, but I am curious.
The standard (and remarkably readable) reference is The Explanatory Supplement to the Astronomical Almanac, P. K. Seidelmann (ed.), 1992. It covers the basics of time measurement and calendrical calculations, among many other topics. Greg
Matt
-- Matt Hellige matt@immute.net http://matt.immute.net _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Keith Wansbrough (Thu, Feb 06, 2003 at 05:46:22PM +0000):
Stefan Karrmann <sk@mathematik.uni-ulm.de> writes:
A sound base for a Time implementation should use TAI (temps atomique international), c.f. <http://cr.yp.to/libtai.html>.
I disagree; I think UTC is quite sufficient, and will match the users' expectations much better. (executive summary: UTC is the time on your watch (+/- timezone of course), TAI is behind by a few seconds, and this difference changes each time there's a new leap second).
However, the reference above is not to TAI, but to a library called libtai. I don't know anything about this; Stefan, maybe you could tell us some more?
One TAI second is defined as the duration of 9192631770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium atom (quoted from <http://cr.yp.to/libtai/tai64.html>). Therefore, it is easy to add seconds to a TAI-label. If you have a leap-second table, you can easily convert TAI into UTC but not visa-versa (afaik), since in UTC leap-seconds are mapped to the previous second! (You need a leap-flag.)
From UTC to CalenderTime (Gregorian (from 1582) or ISO time) is straight forward.
Libtai is a public domain implementation of 64-bit TAI-labels, which are defined from 1E+11 years before 1970 to 1E+11 years after 1970. Thus this would avoid year 2038 and 2036 bugs of other common time representations. References (some may moved into nirwana): 1. <http://www.boulder.nist.gov/timefreq/general/glossary3.htm> 2. <http://www.boulder.nist.gov/timefreq/pubs/bulletin/leapsecond.htm> 3. <http://sadira.gb.nrao.edu/~rfisher/Ephemerides/times.html> 4. <http://purl.org/DC/elements/1.1/> Sincerly, -- Stefan Karrmann
Hi all, I'm jumping into this a bit late, but I have some good info about time. Two sites that I know about that have good tutorials and white papers are http://www.datum.com/res_technical.html http://www.truetime.com/DOCSn/TTreferencematerial.html In particlar, the paper "Timing and Time Code Reference Book" is very interesting. It explains several different time standards that are currently used, and tells you why UTC needs leap seconds. Pretty much the whole world runs on UTC. All of the common time distribution systems use UTC. Technically, GPS doesn't, but the GPS signal includes the correction to UTC. I understand the argument for using TAI. Maybe internally the libray should use TAI, but default to giving the user UTC? -- Matthew Donadio (m.p.donadio@ieee.org)
Matthew Donadio wrote:
Pretty much the whole world runs on UTC. All of the common time distribution systems use UTC. Technically, GPS doesn't, but the GPS signal includes the correction to UTC. I understand the argument for using TAI. Maybe internally the libray should use TAI, but default to giving the user UTC?
I'd argue that the most important factor is compatibility with the rest of the OS. If the underlying OS doesn't support leap seconds, then nor should the Haskell environment. IOW, the Haskell functions need to be wrappers around the corresponding libc functions (or their Windows equivalents). I.e.: Haskell C getClockTime gettimeofday toCalendarTime localtime toUTCTime gmtime toClockTime mktime -- Glynn Clements <glynn.clements@virgin.net>
Matthew Donadio (Fri, Feb 07, 2003 at 01:13:30PM -0500):
Pretty much the whole world runs on UTC. All of the common time distribution systems use UTC. Technically, GPS doesn't, but the GPS signal includes the correction to UTC. I understand the argument for using TAI. Maybe internally the libray should use TAI, but default to giving the user UTC?
Yes, TAI should be the base to add seconds. (It's a total function!) Two functions should connect it to UTC, e.g.: taiutc :: UTCleaps -> TAItime -> (UTCtime, Bool {-isLeap-}) utctai :: UTCleaps -> Bool {- isLeap -} -> UTCtime -> TAItime where newtype UTCleaps = UTCleaps ( [ (TAItime,Bool {- Skipped or Additional -}) ], TAItime {- valid (at least) until -} ) newtype UTCtime = UTCtime Rational Note: o It is easy to use (utctai leaps False) and (\t -> first (taiutc leaps t)) as a simple interface. o Only, programs that run several month have to update the leap-seconds table more than once. On UTCtime we can build ISO, Gregorian, Julian, etc. calendars. Cheers, -- Stefan Karrmann
participants (7)
-
Glynn Clements -
Gregory Wright -
Keith Wansbrough -
Matt Hellige -
Matthew Donadio -
Simon Peyton-Jones -
Stefan Karrmann