January 2005 - Libraries

RE: Time
by Graham Klyne 27 Jan '05

27 Jan '05

Merely a datum, not a proof-of-correctness... [[ The grammar element time-second may have the value "60" at the end of months in which a leap second occurs -- to date: June (XXXX-06- 30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D for a table of leap seconds. It is also possible for a leap second to be subtracted, at which times the maximum value of time-second is "58". At all other times the maximum value of time-second is "59". Further, in time zones other than "Z", the leap second point is shifted by the zone offset (so it happens at the same instant around the globe). ]] -- http://www.ietf.org/rfc/rfc3339.txt #g -- At 09:46 27/01/05 +0000, Simon Marlow wrote: >On 26 January 2005 21:27, Peter Simons wrote: > > > Marcin 'Qrczak' Kowalczyk writes: > > > > >> 23:59:60 > > > > > [...] and UTC doesn't have leap seconds. > > > > Just a minor point ... it does, see above. ;-) I'm not sure > > how the loss of a second would be expressed, though. > >This is quite a subtle point. What people have been referring to as >"UTC seconds" I would call time_t. time_t does not include leap seconds >in its count; rather the actual duration of a second gets longer around >a leap second. > >UTC is a calendar in which some minutes have 61 seconds. > >My library in fact maps both seconds to 23:59:59 at a leap second: > > > let t = CalendarTime{ ctYear=1998, ctMonth=11, ctDay=31, ctHour=23, >ctMin=59, ctSec=59, ctPicosec=0, ctTZ=utcTimezone } > > clockTimeToUTCTime (fromJust (calendarTimeToClockTime t)) >Thu Dec 31 23:59:59 UTC 1998 > > clockTimeToUTCTime (fromJust (calendarTimeToClockTime t) + 10^12) >Thu Dec 31 23:59:59 UTC 1998 > > clockTimeToUTCTime (fromJust (calendarTimeToClockTime t) + 2*10^12) >Fri Jan 1 00:00:00 UTC 1999 > >(adding 10^12 for a second because ClockTime is measured in >picoseconds). > >Cheers, > Simon >_______________________________________________ >Libraries mailing list >Libraries(a)haskell.org >http://www.haskell.org/mailman/listinfo/libraries ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Time Library Organisation
by Ashley Yakeley 27 Jan '05

27 Jan '05

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

4 7

RE: Time
by Simon Marlow 27 Jan '05

27 Jan '05

On 26 January 2005 21:27, Peter Simons wrote: > Marcin 'Qrczak' Kowalczyk writes: > > >> 23:59:60 > > > [...] and UTC doesn't have leap seconds. > > Just a minor point ... it does, see above. ;-) I'm not sure > how the loss of a second would be expressed, though. This is quite a subtle point. What people have been referring to as "UTC seconds" I would call time_t. time_t does not include leap seconds in its count; rather the actual duration of a second gets longer around a leap second. UTC is a calendar in which some minutes have 61 seconds. My library in fact maps both seconds to 23:59:59 at a leap second: > let t = CalendarTime{ ctYear=1998, ctMonth=11, ctDay=31, ctHour=23, ctMin=59, ctSec=59, ctPicosec=0, ctTZ=utcTimezone } > clockTimeToUTCTime (fromJust (calendarTimeToClockTime t)) Thu Dec 31 23:59:59 UTC 1998 > clockTimeToUTCTime (fromJust (calendarTimeToClockTime t) + 10^12) Thu Dec 31 23:59:59 UTC 1998 > clockTimeToUTCTime (fromJust (calendarTimeToClockTime t) + 2*10^12) Fri Jan 1 00:00:00 UTC 1999 (adding 10^12 for a second because ClockTime is measured in picoseconds). Cheers, Simon

2 1

RE: Time
by Simon Marlow 27 Jan '05

27 Jan '05

On 26 January 2005 00:27, Ashley Yakeley wrote: > In article <5.1.0.14.2.20050125161230.02e21620(a)127.0.0.1>, > Graham Klyne <GK(a)ninebynine.org> wrote: > >> I believe I'm in a minority and don't challenge the majority >> decision, but I would prefer a date/time representation based on a >> pair (days,ticks), where ticks is a count of some suitable fraction >> of a second. My reasons have been recorded here previously ... I'll >> dig out a reference if anyone cares. > > I think (days,ticks) might be worth examining for UTC time, since UTC > has a variable number of seconds for each day (usually 86400, but may > be one more or one less). I like the idea of having a single notion of absolute time, which is independent of TAI or UTC time. You can do arithmetic on absolute time (add/subtract absolute units of time, find absolute time differences), and convert to/from TAI and UTC. My library happens to keep absolute time as TAI seconds since the epoch, but it doesn't have to. A representation using (days,ticks) sounds like it might be hard to do arithmetic on, though. Cheers, Simon

3 2

RE: Time
by Bayley, Alistair 26 Jan '05

26 Jan '05

> From: Peter Simons [mailto:simons@cryp.to] > > A bank, for example, can't store its financing data in TAI, > because TAI knows only the difference between two points in > time. Between now and some day in the future, exactly 'n' > seconds will pass. If that day is in the sufficiently > distant future though, your mortgage repayment won't be due > on April 1st some year, but on March 31st a second before > midnight. Therefore these applications really need to store > _calendar time_, which would be UTC et all. Ahh, excellent example. So are there disadvantages to using, say, UTC, as the underlying representation? We can map UTC to TAI accurately for past and current dates (and those in the near future), and for the more distant future we accept that any conversion to TAI is only an approximation. Is there a need to support two different implementations? The types of systems I deal with would all use UTC/calendar-time, and I don't think I'd ever have a use for TAI (but I'm sure there are people that do). > From: Graham Klyne [mailto:gk@ninebynine.org] > > Turning to the more general discussion of time... how complex a time > library do we want? What sorts of things do folks actually > want to do with time values most of the time? One specific: I've used a language to implement a time-keeping system where addition of time durations was performed modulo 24hours e.g. if you added 2 hours to 23 hours, you got 1 hour. That made it impossible to sum the hours in a 40-hour week using that datatype... So being able to specify a variety of input and output formats for durations is desirable. I may want to specify 2 weeks, or 14 days, or 336 hours. I view timezone support as a layer over a correctly functioning UTC implementation. You want to represent all your times in UTC (well, something canonical) and have functions to input/output those in a variety of formats and timezones. Also, a String -> IO Time function that used the current locale to determine the timezone would be ideal for localising apps where the user entered times. I've seen criticism of the Java time support, mainly because it required you to specify a Calendar i.e. you had to perform all time operations in the context of a Calendar. While correct, it was considered too complex for simple things like "get me the time now". So maybe a simple default library, using the Gregorian calendar, that's capable of answering questions like: - how do I get the current time? - how do I find the start of the next quarter? - what day of the week is it today? - how many Mondays are in this month? - etc Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

3 2

RE: Time
by Bayley, Alistair 26 Jan '05

26 Jan '05

> From: Peter Simons [mailto:simons@cryp.to] > > Well, there _is_ an absolute notion of time, that is what TAI is. > The reason why that seems to be of little use for the general > public is that this absolute time scale just doesn't correspond > to calendar time. There simply is no accurate mapping between TAI > and the information 2043-04-01T00:00:00. I assume that the only reason we can't establish a mapping between 2043-04-01T00:00:00 and TAI is because of the leap seconds problem. I assume we can map accurately between TAI and (say) 2001-01-01T00:00:00 (Gregorian). And I assume that we just accept that the TAI <-> UTC/Gregorian/whatever mapping cannot be accurate for times in the future. My point was that when you say "here is a time, specified as x", where x is one of TAI / UTC / Julian+TZ / Gregorian+TZ / etc, any of the x's is as good as any other (as long as the time is not in the future), and the internal representation of time could be any one of, or none of x. I think people are proposing TAI as an internal representation, but it's not necessary, and I'm wondering if it's even desirable. What are the limits on a 64bit TAI implementation? 64 bits gives you (signed integers): +/- 9223372036854775807: Assuming milliseconds (is this reasonable?): 922337203685477.5807 secs ~= 106751991167 days ~= 292471208 years OK, that seems plenty... ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

5 5

Time
by Ashley Yakeley 26 Jan '05

26 Jan '05

There's been a lot of discussion here and other lists of replacing System.Time, and indeed Simon M. is working on a replacement proposal: <http://www.haskell.org/~simonmar/time/NewTime.html> <http://www.haskell.org/~simonmar/time/NewTime.hsc> Rather than talk about specific Haskell code, I'd like to discuss the measurement of time in general, how these concepts might be expressed in Haskell, and what people might want from a time library. Rather than propose anything, I want to try to ask some of the right questions. Scales of Time -------------- First of all, there are two obvious ways of measuring time. One is "clock time", "absolute time", or "atomic time", time as would be measured by a perfect clock. The standard for this is "International Atomic Time", or TAI, which is measured by an international system of atomic and maser clocks under the auspices of BIPM. TAI was established in 1955. The various clocks around the world are kept synchronised by simultaneous observation of transmissions from GPS satellites, though BIPM is considering other methods. In addition to distributing time live, BIPM issues post hoc corrections to create an even more accurate timescale. TAI is nothing more than a continuous count of "SI seconds", which are a fixed period of time defined in terms of a particular physical process. Nevertheless TAI is usually represented in "date and time" format, even as those "SI days" drift away from real Earth days. The other way is in terms of the earth's rotation against the sun. To get an accurate and even timescale, the earth's rotation is measured against the stars and distant radio sources, and then corrected for the annual orbit of the earth around the sun. Doing this at a particular place on the earth gives a version of "Universal Time" known as UT0. Despite its name, UT0 varies from place to place due to the motion of the poles. Correcting for polar motion yields UT1, which is a single scale for all places. Note that the sun itself may be up to 16 minutes off UT0 due to the "equation of time", that is, the motion of the earth on its elliptical orbit. UT1 is a continuous count of "Earth days". Since the earth does not keep perfect time, the precise length of these days varies. UT1 and TAI were synchronised at the precise beginning of 1958 as observed at Greenwich. Since then, the two have drifted apart, with UT1 days being about 2ms longer than the "SI days" (= 86400 SI seconds) of TAI. The difference between the two is currently around 32 seconds. A parameter known as "Delta T" tracks the difference: Delta T = TT - UT1 = TAI - UT1 + 32.184s The current value of Delta T is about 64s. The offset constant of 32.184s has a historical reason: that and some of the other historical details I've omitted. TT is something called "Terrestrial Time". Neither UT1 nor TAI is used for civil time, however. Instead, a timescale known as UTC was defined in 1972. Like TAI, UTC counts SI seconds, and the difference is always an integer number of seconds (currently 32). Like UT1, UTC does not drift with real Earth days, and the difference is always kept with 0.9s. This is managed by inserting or removing "leap seconds" into the timescale at the end of June or December. The IERS is responsible for determining leap seconds. Unfortunately, the earth's rotation is not very predictable. Indeed even human actions such as damming large rivers near the equator are enough to make a difference to timekeeping. As a result, the IERS gives only six months' notice of its decision to adjust UTC or not. For instance, leap seconds used to be regular insertions about every 18 months, but there hasn't been one since the one at the end of 1998. All adjustments so far have been insertions, though removals are also possible: David Mills claims his popular NTP time distribution software can handle that, though other software might potentially have problems. UTC might be thought of as an integer count of days, together with a continuous count of seconds. Most days have 86400 seconds in them, a few have 86401, and some might have 86399. Time Zones ---------- So TAI, UT1, and UTC are the most commonly used timescales. Of course, when it's daytime in one place, it's nighttime somewhere else, so local "time zones" are defined. Time in each zone is a fixed offset to UTC, usually a whole number of hours though in some zones (such as the single one for all of India) it's on a half-hour. Each zone might nominally refer to a meridian or line of longitude: while meridians are more relevant to UT1, they give some notion of the accuracy of the time in the zone as compared to the motion of the sun through the sky. The meridian for Eastern Standard Time, for instance, is at 75dW, the one for Pacific Standard Time is 120dW. Confusingly, in some zones in the northern hemisphere, or some parts of some zones, time is offset by an additional hour during some summer period. The precise days in the year vary from place to place, and the parts of the zones that are subject to this are not always simply defined. For instance, the American state of Indiana has three separate regions, with three different time behaviours: most of it uses EST without summer offset, another part uses EST with an offset in the summer, and another part uses CST with an offset in the summer. Time zones informally have three-letter acronyms, however I believe these are not standardised. Specifying the actual time difference is standard in software protocols. Calendrics ---------- A calendar is a system of naming periods of time: usually these are periods of days, though the boundary between named days may vary. A calendar may be determinate or it may involve some kind of observation, it may or may not track the year as defined in various ways, it may or may not track the period of the moon with varying degrees of accuracy, etc. It may involve one or more separate cycles, such as the seven-day "week" cycle. It may have associated with it certain "special" days that may be defined in related or unrelated ways. It's worth noting that even the length of the year is not a well-defined thing. The length of time between March equinoxes differs from the length of time between June solstices and so on, since the solstices and equinoxes are drifting relative to each other as they precess around the ellipse of the earth's orbit. Time Library ------------ So what does this mean for Haskell? Mostly that there is a very wide range of time-related needs for various applications. Ideally a standard library would help with some of these without prejudicing others. Here are some things that I think ought to be kept in mind even though some of them may be beyond the scope of a standard library, together with some issues: * Basic types for time Should there be different types for TAI/UT1/UTC? What about separate difference types? What resolution should be used? Should we use fixed-point numeric types? Should time types be parameterised by underlying numeric type? * Converting between timescales TAI/UTC conversion means knowing and predicting leap-seconds. This information changes over the years. What about the backwards extension of UTC to before it was created? TAI/UT1 conversion means a function for the earth's rotation. This too is dependent on changing information. What sort of approximations would be needed? If both conversions are provided, would it be appropriate to provide guarantees about the calculated difference between UT1 and UTC? * Converting between different zones Should a time-zone be a first-class object? What type would it use, would a difference type be appropriate? * Calculating summertime zone adjustments This is probably a bit much for a standard library, especially as official definitions change occasionally. Nevertheless, some thought about this may be helpful. For instance, when Seattle moves from PST to PDT, has it actually moved time zones? Or is it in the same time zone, but switched "time offsets"? What's the best terminology? * Getting the current time and zone Which timescales should be available? Different platforms may have different information available. * Calendrics What about functions for working with Gregorian calendar information? I'm guessing other calendars should probably be left to others. * Displaying and parsing time in different zones Which standard formats should be covered? Would a field-based "printf" system be useful here? * General organisation Is it worth splitting it into more than one module? -- Ashley Yakeley, Seattle WA

11 16

RE: [Haskell-cafe] File path programme
by ariep＠xs4all.nl 26 Jan '05

26 Jan '05

On 26 January 2005 16:53, Simon Marlow wrote: > On 26 January 2005 15:38, Keean Schupke wrote: > >> Not at all. You just include some nice operation in the class: >> >> emptyPath :: Path p => p >> appendPath :: Path p => p -> String -> p >> >> etc... >> >> So it is an abstract datatype and class. The user never needs to touch >> the concrete type, even though they use it... The types remain >> polymophic. > > The types can't remain completely polymorphic - at some point you have > to say what type you want. Because an ambiguous Path constraint cannot > be resolved, the program will have to mention either Win32Path or > PosixPath, at which point it becomes non-portable without conditinoal > compilation. > Can't the actual instance be determined by some appropriate IO function? For example: getHomeDirectory, getTempDirectory, getCurrentDirectory :: IO Win32Path under windows; getHomeDirectory, getTempDirectory, getCurrentDirectory :: IO PosixPath in a posix system. In this way, many programs can be written in terms of polymorphic functions (such as appendPath :: (Path p) => p -> String -> p) combined with e.g. getHomeDirectory and be fully portable. Someone may want to be able to store and retrieve paths, so we would need platform-specific (or actually instance-specific) functions parsePath and showPath. These functions should not be part of the class Path, because their types must be monomorphic, like that of getHomeDirectory. If it must be possible to work with non-native paths as well, we could also make parsePath and showPath class members and have separate parseNativePath and showNativePath with monomorphic type signatures. Programs that need more than these common getHomeDirectory-like functions are bound to be non-portable anyway, right? Might it be possible or useful to make Uri an instance of Path as well? Regards Arie Peterson

1 0

RE: [Haskell-cafe] File path programme
by Simon Marlow 26 Jan '05

26 Jan '05

On 26 January 2005 15:50, Keean Schupke wrote: > You could define a type in the library using conditional compilation: > > #ifdef Unix > type SystemPath = UnixPath > #endif > > #ifdef Windows > type SystemPath = WindowsPath > #endif > > > Then you do: > > let myPath = (emptyPath :: SystemPath) in ... Portable library APIs are not supposed to vary between platforms. Cheers, Simon

1 0

RE: [Haskell-cafe] File path programme
by Simon Marlow 26 Jan '05

26 Jan '05

On 26 January 2005 15:38, Keean Schupke wrote: > Not at all. You just include some nice operation in the class: > > emptyPath :: Path p => p > appendPath :: Path p => p -> String -> p > > etc... > > So it is an abstract datatype and class. The user never needs to touch > the concrete type, even though they use it... The types remain > polymophic. The types can't remain completely polymorphic - at some point you have to say what type you want. Because an ambiguous Path constraint cannot be resolved, the program will have to mention either Win32Path or PosixPath, at which point it becomes non-portable without conditinoal compilation. Cheers, Simon

1 0