- Libraries - Haskell.org

RE: System.Time.Clock Design Issues
by Simon Marlow 04 Feb '05

04 Feb '05

On 03 February 2005 13:01, Ashley Yakeley wrote: > It's true that POSIX is an inherently wrong representation of UTC, as > it is wrong at leap seconds. The trouble is, what you are suggesting > is a type that is wrong in a much more complicated way: it starts off > as a correct representation of TAI, and turns into a representation > of UTC that is also wrong at leap seconds. > > Let us suppose we have a system clock that keeps POSIX time, and a > Haskell function, getClockTime, that returns the current ClockTime you > are suggesting. I compile a program that calls this function. > > At first getClockTime returns the correct TAI time, which can be > converted into the correct UTC time. Then, in two years' time, a leap > second is announced. During the leap second, the system clock is > stepped, and getClockTime returns the wrong TAI time converted to the > wrong (by up to a second) UTC time. After the leap second, > getClockTime continues to return the wrong TAI time, but it is > converted to the correct UTC time. Actually you'd probably get a correct UTC time, because the conversion would be done by first converting to POSIX time, and then asking the C library to convert to UTC. The errors cancel out. But I agree with the rest of what you say. Basically, providing TAI time is problematic because we can't implement it correctly, for future times, on systems that only provide POSIX time. At this point I'm not sure what is best, I'm still quite disturbed by the idea of basing the definition of the Haskell Time library on what is basically a mistake in the definition of POSIX :-) Cheers, Simon

5 6

RE: Type for Current Time Function
by Bayley, Alistair 04 Feb '05

04 Feb '05

> From: Simon Marlow [mailto:simonmar@microsoft.com] > > I think I don't really understand the (days,ticks) representation. > Could somebody explain the meaning of arithmetic on this type? > > Is the ticks field supposed to be limited to a day's worth? > Or a day + a leap second? I'm assuming that it's UTC (i.e. ticks = day plus optional leap second), although others might think differently... > Can I add ticks to a time? If so, don't you need leap second > info to do > the normalisation? Or, if normalisation doesn't happen, you need leap > second info to convert to UTC, right? The only conclusion seems to be > that either you can't add ticks to a time, or you need leap > second info > which is what we're trying to avoid. Isn't this a general problem, rather than a specific representation problem? The only representation where you wouldn't have to know about leap seconds would be TAI. E.g. there was a leap second on 1997-06-30 23:59:60 UTC, so: - Q: how many seconds are there between 1997-06-30 00:00:00 UTC and 1997-07-01 00:00:00 UTC ? A: 86401 - Q: how many days are there between 1997-06-30 00:00:00 UTC and 1997-07-01 00:00:00 UTC ? A: 1 - Q: how long is the period between 1997-06-30 00:00:00 UTC and 1997-07-01 00:00:00 UTC ? A: 1 day 1 second, or 1 day ? (I guess just 1 day, as a day can be 86401 seconds long.) - Q: how many seconds in a day? A: 86400 (or maybe this is undefined, as it could be 86399, 86400, 86401?) - Q: what is 1997-06-30 00:00:00 UTC plus one day? A: 1997-07-01 00:00:00 UTC - Q: what is 1997-06-30 00:00:00 UTC plus 86400 seconds? A: 1997-06-30 23:59:60 UTC It gets hairy when you start thinking about durations, and I would like to see duration arithmetic in the library. I don't have any good ideas about how to handle this. 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. *****************************************************************

1 0

RE: System.Time.Clock Design Issues
by Simon Marlow 04 Feb '05

04 Feb '05

On 04 February 2005 11:00, Glynn Clements wrote: > Simon Marlow wrote: > >> The time zone issue is a red herring. You can use UTC calendar time >> exclusively if you want. > > I'm not entirely sure what you mean by that, but you need local > calendar times for date arithmetic, e.g. "one month from now": Yes of course. That comment was in reply to Ashley's comparison of POSIX time and calendar time, where he said that "calendar time ... may be dependent on timezone". I was just pointing out that the fact that calendar time includes the timezone is not a limitation. Cheers, Simon

1 0

System.Time.Clock Design Issues
by Ashley Yakeley 04 Feb '05

04 Feb '05

Time turns out to be complicated by nature, and it's not possible to be as simple as we'd like and still be completely correct: there's a trade-off between simplicity and correctness. I lean towards correctness myself, I think there are ways of managing extra complexity. We might, for instance, be able to separate some of the less-used functions into another module fairly sensibly. There's also a trade-off between simplicity and usefulness. My earlier message has one idea of where to draw the line, as well as one way of splitting the functionality: <http://www.haskell.org//pipermail/libraries/2005-January/002930.html> Simon suggested naming the two modules "System.Time.Clock" and "System.Time.Calendar". These are the issues that seem to be remaining for the "Clock" module: * Can we assume that gettimeofday always returns UTC rather than TAI time? POSIX says yes. People might set it differently, but there doesn't seem to be any way of detecting that. We can't used time-zone setting AFAIK, because gettimeofday is supposed to be universal time independent of time-zone. My preference is to assume people are following the POSIX standard, since that's the assumption that most software makes (including NTP I believe). * Should there be a TAI type separate from a POSIX time type that the system clock would return? My preference is yes. If necessary we could create a third module for TAI time and explicit leap-second handling, which will keep them out of the way for most people. Separate types is more complication, but the alternatives have their own issues: <http://www.haskell.org//pipermail/libraries/2005-February/003049.html> * 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. -- Ashley Yakeley, Seattle WA

5 8

RE: System.Time.Clock Design Issues
by Simon Marlow 04 Feb '05

04 Feb '05

On 03 February 2005 11:30, Ashley Yakeley wrote: > Sure, we could get rid of it entirely and rely on CalendarTime > everywhere. This is the trade-off I see: > > * POSIX time > > not already necessary > fast retrieval from system clock > fast calculation of time differences and offsets > independent of time-zone > > * Structured calendar time > > already necessary anyway > slow retrieval from system clock > slow calculation of time differences and offsets > may be dependent on time zone The time zone issue is a red herring. You can use UTC calendar time exclusively if you want. I disagree that calendar time has slow calculation of time differences and offsets: - for time differences measured in units of minutes and larger, the broken down calendar time is easier to do calculations on. - for units smaller than a minute, doing calculations with either of them might give wrong results. You need to use TAI time instead. I think you're suggesting that we allow calculations in units of seconds on POSIX time and calendar time, and just document that they don't take into account leap seconds. I'd rather say that you can do accurate calcuations on TAI time, but conversions might be wrong. Second-based calcuation on calendar time can be done by converting to TAI to do the calculation. You can also do second-based calculations ignoring leap seconds on a calendar time if you want. > In summary: > > Using TAI with a limited leap-second table is trading a simple kind of > brokenness (all leap seconds) for a complicated kind (future leap > seconds after some date). That's a good way to put it. I think TAI + calendar time covers all the bases, except that you can't do *really fast* second-based calculations that ignore leap seconds. But (a) I don't think this is something we should encourage and (b) I don't think we should expose an inherently wrong representation of time (i.e. POSIX). For people who want to measure time differences between two points, the library API should encourage them to use units of minutes and larger, which are independent of leap seconds. Cheers, Simon

4 4

RE: System.Time.Clock Design Issues
by Bayley, Alistair 03 Feb '05

03 Feb '05

I'm a bit worried that I'm not keeping up with this, so I'd like to clarify some points for my own benefit: === The current time === - UTC/POSIX/CalenderTime are isomorphic, and represent some idealised notion of time where leap seconds don't exist i.e. a day always has duration 23:59:59. - Most (all?) system clocks return UTC. They may slow down around leap seconds to support this - is this behaviour only seen on systems with NTP? - It's not possible to simply get the number of actual ticks since some epoch; the OS time function may slow down for leap seconds and we can't avoid this. - This means TAI time can only be calculated accurately when we have the full leap second table available. === Durations === - Duration calculations are feasible for UTC at any point, as they're idealised. - Duration calculations are accurate for TAI only where we have the full leap second table, again. - Timing an event using the system timer where the event duration encompases a leap second will be inaccurate. - The duration between times A and B, where A->B encompass a leap second, will be different between UTC and TAI: UTC will not count the leap second, while TAI will include the leap second. - The duration between A and B, where both A & B are in the future (now + 6 months), will be the same in TAI and UTC because with TAI we won't know when the leap seconds are, so we assume and idealised calendar. 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. *****************************************************************

7 10

Time library design proposal
by S. Alexander Jacobson 03 Feb '05

03 Feb '05

I read the discussion of Time Library organization, but did not feel like it arrived anywhere. The current design seems like it was expedient for its time, but does not feel particularly robust. It does not handle typical usecases well and provides little protection from user error. So I'm going to take a shot at a proposal: ---- The Y2K problem --------------- It would be nice if the library was explicit about whether year was 2 or 4 digits. Why not define year like this: newtype Year = Year Int -- don't export constructor mkYear century centyear = Year (100*century+centyear) mkBigYear millenium cent centyear = ... Allow Dates without Times ------------------- There are lots of contexts in which you want a date and not a time e.g. storing birthdates. Is there any reason the Time library shouldn't have a standard Date type e.g. data Date = {month::Month,day::Day,year::Year} Don't allow imposible weekdays ------------------------------ Weekday and yearday seem like they should be functions on this Date type and not part of the datastructure (you shouldn't be able to produce weekdays that don't match dates). weekDay::Date->WeekDay Don't allow impossible times ---------------------------- The type of hour minute and second should protect the user from 28 o'clock and making appointments for 31:101 PM So we probably want: data Hour = H0 | H1 | H2 ... H23 data Minute = M0 | M1 | M2 ... M59 data Second = S0 | S1 | S2 ... S59 data AMPM = AM | PM Times Types ----------- There are also lots of contexts where you want a time but not a date e.g. an alarm clock.... data Time = {hour::Hour ,minute::Minute ,second::Second ,millis::Int ,isDST::Bool, ,timeZone::TimeZone } If you have a leap second time that doesn't work in this model, round it! The 99.9999% case does not need to be sacrificed for the occasional physicist who need to know that the time is is 24:00:03. Re millis, yes it seems like it should be Rational, but this is human meaninful time. And humans don't care about millis. We can then produce a DateTime as data DateTime = DateTime {date::Date,time::Time} Epochal High Precision Time -------------------------- If you are doing physicist calculations, then use: data EpochTime a = EpochTime {seconds::Integer ,fraction::Ratio a ,precision::Integer } precision specifies the maximum size of the denominator of the fraction. epochTimeToDateTime::Epoch->DateTime The existing TimeDiff is totally bizarre. If tdSec == 3600 is that an error or is that the same as tdSec == 0 and tdHour == 1? How many months are a difference in months? It all seems too application specific to belong in a library. I don't have a particular good idea here. I think EpochTime does what you need in a library. The last major element we need is: getEpochTime::IO EpochTime Analogous to the old getClockTime but includes the resolution of the system clock. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

8 10

RE: System.Time.Clock Design Issues
by Simon Marlow 03 Feb '05

03 Feb '05

On 03 February 2005 16:32, Scott Turner wrote: > "Simon Marlow" <simonmar(a)microsoft.com> wrote: >> You can still do accurate calculations on calendar times in the >> future, and that's what matters. > > However, the relationship between seconds and the future calendar is > not known. A specific second such as 2005-12-31T23:59:59 may turn out > not to occur. So even CalendarTime is not safe from leap seconds. Yes, I was aware of that but trying not to confuse the issue too much (I mentioned it in a later message). > On 2005 February 03 Thursday 08:00, Ashley Yakeley wrote: >> During the leap second, the system clock is >> stepped, and getClockTime returns the wrong TAI time converted to the >> wrong (by up to a second) UTC time. After the leap second, >> getClockTime continues to return the wrong TAI time, but it is >> converted to the correct UTC time. > > Until there's a system call that provides up-to-date information > about leap seconds, the above-quoted scenario can occur. Since > future conversions between calendar time and TAI are likely > incorrect, how about raising an exception? Actually I very nearly proposed that in an earlier message. You could also do the slightly less drastic: canConvertAccuratelyToCalendarTime :: TAI -> IO Bool and the reverse. Cheers, Simon

3 3

RE: System.Time.Clock Design Issues
by Simon Marlow 03 Feb '05

03 Feb '05

On 03 February 2005 10:44, Ashley Yakeley wrote: > OK, so we have > > * POSIX time > > Can do accurate calculations on calendar times. > Can store UTC times reliably. > Cannot store TAI times reliably. > Broken for all leap seconds. > > * TAI time with limited leap-second table > > Can do accurate calculations on calendar times. > Cannot store UTC times reliably. > Can store TAI times reliably. > Broken for leap seconds after table runs out. > > Which of these is better? The point is that everything you can do with a POSIX time you can also do with a calendar time, which we need anyway. So why have a POSIX time too? Cheers, Simon

3 3

RE: Text.PrettyPrint.HughesPJ inserting blank lines
by Simon Peyton-Jones 03 Feb '05

03 Feb '05

I recall that making 'empty' a unit for <> and <+> and $$ was one of my main goals in revising John Hughes's library. I recall also that it got more complicated than I expected, and I didn't feel very satisfied with the result, though it has worked pretty well for years. If anyone wants to peer into the implementation and add combinators along the lines of those below, that's fine with me. Vertical operations should be easier to do than horizontal ones, because the question of where to insert line breaks doesn't arise. Whether the code below does the job, I couldn't say without looking in detail -- and I'm hoping someone else will do that. It's crucial to maintain the property that you can print an arbitrary long document in bounded space. It would be a great service to also add Haddock documentation, please! Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Christian | Maeder | Sent: 02 February 2005 12:58 | To: Tomasz Zielonka | Cc: libraries(a)haskell.org | Subject: Re: Text.PrettyPrint.HughesPJ inserting blank lines | | Tomasz Zielonka wrote: | > This is ugly: | > | > x $++$ y = (x <> text "") $+$ text "" $+$ (text "" <> y) | > | > However, I don't know if it's OK that (show (empty $++$ empty) == | > "\n\n"). | | I want "empty" to be a unit of $++$ as well, so that | | -- | list version of '($++$)' | vsep :: [Doc] -> Doc | vsep = foldr ($++$) empty | | works. Therefore I suggest: | | -- | vertical composition with a specified number of blank lines | aboveWithNLs :: Int -> Doc -> Doc -> Doc | aboveWithNLs n d1 d2 = if isEmpty d2 then d1 else | if isEmpty d1 then d2 else | d1 $+$ foldr ($+$) d2 (replicate n $ text "") | | -- | vertical composition with one blank line | ($++$) :: Doc -> Doc -> Doc | ($++$) = aboveWithNLs 1 | | Cheers Christian | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0