This is one way the time libraries might be organised. I think the functionality splits cleanly into two separate modules. "Time" module (System.Time? System.DateTime.Time?) * TAI/UTC arithmetic and conversions, leap-second tables * possibly UT1 types and conversions, Julian days and dates * getting the current time "Date" module (System.Date? System.DateTime.Date?) importing Time module * time zones * getting the locale time zone * converting times to "calendrical" format, Gregorian and possibly also Julian * calendrical arithmetic e.g. one month after March 31st * possibly "incomplete dates" e.g. "May 1" for all years * parsing and showing dates and times Left for other libraries (standard or user) * sunrise/sunset, moon phase, solstices & equinoxes, etc. * figuring out time zone from position on Earth * civil summertime zone adjustment calculation * calendar systems other than Gregorian and Julian * generalised sets over time e.g. "2pm-4pm every 4th Saturday of the month" -- Ashley Yakeley, Seattle WA
Ashley Yakeley wrote:
This is one way the time libraries might be organised. I think the functionality splits cleanly into two separate modules.
"Time" module (System.Time? System.DateTime.Time?)
* TAI/UTC arithmetic and conversions, leap-second tables
Im not an expert - but arn't leap-seconds connected with which calendar you are using (not all calendars have 365 days a year)
* possibly UT1 types and conversions, Julian days and dates
* getting the current time
I would think that Time should be fudge-factor free... simply a number of milliseconds after the epoch... perhaps a 64bit number to avoid the unix Y2K problem which I think is around 2030 (for a 32bit number)... Another reason is daylight-savings (or British-Summer-Time) which means the time of day changes, but of course when it changes from GMT to BST depends on the calendar. As such calculating localtime (hour of the day) depends on the day of the year for some timezones... so this should be with the other calendar functions. So my vote goes for the unixy way of doing it, with a simple getTime function that returns milliseconds after the epoch, and a library of timezone/alternate calendar functions... allowing: localtime getTime Paris Mayan) -- to get the local time in paris calculated using the Mayan calendar. Keean.
In article <41F75D46.90704@imperial.ac.uk>,
Keean Schupke
So my vote goes for the unixy way of doing it, with a simple getTime function that returns milliseconds after the epoch,
Unfortunately "the unixy way of doing it" and "a simple getTime function that returns milliseconds after the epoch" are not the same thing at all. Read the section "Unix system time and the POSIX standard" on this page: http://www.ucolick.org/~sla/leapsecs/onlinebib.html Wikipedia also explains it. "[Unix time] is sufficiently similar to a linear representation of the passage of time that it is frequently mistaken for one": http://en.wikipedia.org/wiki/Unix_time But you should probably read my earlier message first if you haven't already: http://www.haskell.org/pipermail/libraries/2005-January/002908.html -- Ashley Yakeley, Seattle WA
Ashley Yakeley wrote:
So my vote goes for the unixy way of doing it, with a simple getTime function that returns milliseconds after the epoch.
Sorry, shouldn't have mentioned unix...
My vote goes for a TAI style time, in milliseconds (64bit resolution, or an Integer would be even better), with a library to convert this 'absolute' time into a local date/time... The functions would look a bit like unix ie: type Time = Word64 -- or Integer getTime :: IO Time localtime :: Calendar c => Time -> TimeZone -> c Calendar is a type dependant on the calendar format, so for the normal calendar something like: data MyCalendar = MyCalendar { hour :: Int, minute :: Int, second :: Int, dayOfTheWeek :: Int, dayOfTheMonth :: Int, month :: Int, year :: Int } dateTime = localtime getTime UK :: MyCalendar Of course, the time in any timezone may depend on the calendar... I suspect daylight-savings, as it depends on particular dates should only be applied to the normal calendar - and not to alternate calendars... in effect I think you want something like: class Calendar c where localtime :: Time -> TimeZone -> c Then each calendar instance can use or ignore the timezone as appropriate. Keean.
In article <41F77995.9070700@imperial.ac.uk>,
Keean Schupke
My vote goes for a TAI style time,
TAI time isn't usually available. System clocks are usually set to "Unix time", which is almost, but not quite, isomorphic with UTC. Sometimes they're set to a timezone-adjusted variant. I think conventional "best practice" is to have the system clock set to Unix time, synchronised by NTP. Together with its "leap-second bit", set for the day that will have the extra second, NTP time is unambiguous, even if Unix time isn't. This explains how NTP works with leap-seconds: http://www.eecis.udel.edu/~mills/leap.html
in milliseconds
This is not fine enough. The current System.Time uses picoseconds, for instance. -- Ashley Yakeley, Seattle WA
Ashley Yakeley
in milliseconds
This is not fine enough. The current System.Time uses picoseconds, for instance.
What others do: - Unix uses microseconds (gettimeofday) and nanoseconds (clock_gettime). On my PC both are actually accurate to microseconds though. - Java uses milliseconds. - .NET uses 100ns ticks. I guess this is what Windows NT uses. - Python uses a Python float (C double) for the number of seconds since the Epoch, which gives about 0.2us of resolution until 2038. On my PC the gettimeofday() call takes almost 2us to complete. So I would guess nanoseconds are enough. Or maybe the actual unit should be left implementation-dependent. Nanoseconds have a nice property that 10^9 fits in 2^30. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
Keean Schupke
I would think that Time should be fudge-factor free... simply a number of milliseconds after the epoch...
A timestamp may even be an opaque value, as long as you can get the difference (in seconds and fraction of) between two time stamps, and convert it to calendar data. (Perhaps it would also be nice to output a timestamp directly in some format?) So it may not need to be specified. Or is it necessary to be able to store and retrieve (the internal representation of) timestamps? It then doesn't *really* matter whether the internal format uses TAI or UTC, but time differences in UTC must be compensated for leap seconds (so that computations don't go faster or slower because of them). -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Ketil Malde
It then doesn't *really* matter whether the internal format uses TAI or UTC, but time differences in UTC must be compensated for leap seconds (so that computations don't go faster or slower because of them).
It's not possible to avoid irregularities around leap seconds on at least some systems, because many systems actually slow down their Unix second counter (NTP synchronized), and many systems don't (not NTP synchronized) - you can't determine programmatically which is the case. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
participants (4)
-
Ashley Yakeley -
Keean Schupke -
Ketil Malde -
Marcin 'Qrczak' Kowalczyk