November 2003 - Libraries

RE: Time library discussion (reprise)
by Simon Marlow 14 Nov '03

14 Nov '03

> > -- | A representation of absolute time, measured as > picoseconds since > > -- the epoch, where the epoch is 1 January 1970 00:10 TAI. > > data ClockTime -- abstract > > instance of (Eq, Ord, Num, Enum, Integral, Show, Read) > > > > -- | returns the current absolute time > > getClockTime :: IO ClockTime > > The advantage (what I tried to say in my previous message) is that > something like > > t1 <- getClockTime > : > t2 <- getClockTime > print ("Elapsed time: "++ show (t2-t1)++" seconds") > > would work correctly, and not just work "most of the time", like it > would with UTC. This is the nub of the problem: the proposal does provide such functionality, but it isn't implementable on Unix systems. > > data Timezone -- abstract > > > -- | Make a 'Timezone' from an offset, in seconds relative to UTC, > > -- which must be smaller in magnitude than @+/-12*60*60@. > > timezoneFromUTCOffset :: Int -> Timezone > > Don't you also need a specific time? We have UTC+0100 in the winter, > but +0200 in summer (or was it the other way around? :-) > > Perhaps we should separate between Timezones (the TLAs) and their > offsets. We could have a > > localTime :: Timezone -> ClockTime -> CalendarTime > > and make the offset, but not TZ, a part of CalendarTime. Would it > then make (more) sense to compare CalendarTimes? At least it wouldn't > need to involve timezone tables. I think you're assuming that the timezone TLAs don't represent fixed offsets relative to UTC. I assume that they do. For example, here we are in timezone GMT at the moment (== UTC+0000), but we switch to BST in the summer (UTC+0100). I just looked up the list of timezone abbreviations, and it's pretty short. The library could easily include this list. Isn't your localTime above exactly the same as 'clockTimeToCalendarTimeTZ' in the proposal? > data Timezone = UTC | GMT | PDT ... deriving ... > > data TZOffset = -- abstract (or just an Int) > instance Num TZOffset -- auto conversion from int, etc > tzToOffset :: Timezone -> TZOffset Not sure what this would buy us. > > TODO: add isDSTCalendarTime? (returns True if the specified > > CalendarTime is in daylight savings). How do we say "what's the > > current timezone in X", taking into account DST? > > Exactly. Yes, but don't confuse geographical locations with timezones. A given geographical location can be in one of several timezones, depending on the ClockTime. Perhaps we want a way to map geographical locations to timezones. You can do this in Unix (sort of), like this: $ TZ=America/New_York date Thu Nov 13 05:07:26 EST 2003 i.e. New York is currently in the EST timezone. > > - Need to define the meaning when the offset doesn't exist. > > eg. adding a day at the end of the month clearly rolls over > > into the next month. But what about adding a month to > > January 31st? > > Perhaps it would be possible to have a more flexible system, where one > could specify things like the last day of the month, the second > Wednesday every second month, and so on? Not sure how it would look, > though. Sure, but let's get the basics right first :-) Cheers, Simon

4 3

RE: Time library discussion (reprise)
by Simon Marlow 14 Nov '03

14 Nov '03

> Where did you find this list? With a little Google searching I found > several conflicting sources: Just used the first one that popped up in google: http://www.timeanddate.com/library/abbreviations/timezones/ I was planning to check this against the zoneinfo stuff in glibc. > > Perhaps we want a way to map geographical locations to timezones. > > Ooh, dangerous. Ok, duly noted. > I recommend reading through the files in tzdata Thanks but no thanks :-) I should point out that my motivation here is just to push the discussion forward until we have a library that everyone is happy with. I have very little interest in the finer points of date/time programming myself, but I'm hoping that those who do will tell me what to do, preferably in the form of patches. In particular I'm hoping that someone will contribute the calendar manipulation part of the library that is currently missing. Cheers, Simon

1 0

Re: ANNOUNCE: attribute 0.1
by Ross Paterson 13 Nov '03

13 Nov '03

[switching to libraries] On Thu, Nov 13, 2003 at 04:29:49PM -0500, Derek Elkins wrote: > Sorry that I'm too lazy to download the the tar.bz2 and see for myself, > but... > > On Thu, 13 Nov 2003 16:06:24 -0500 > "Abraham Egnor" <aegnor(a)antioch-college.edu> wrote: > > that applies those functions to a monadic reference. Instances for > > MRef are provided for both IORef and STRef. > > Assuming MRef is like the below, did you include Lazy.ST too? > > On a more general note, sticking something like MonadRef somewhere in > the heirarchical libs seems like it would be useful. Or perhaps Iavor's > monad library? > > instance MonadRef IO IORef where > newRef = newIORef > readRef = readIORef > writeRef = writeIORef > > instance MonadRef (Lazy.ST s) (STRef s) where > newRef = Lazy.strictToLazyST . newSTRef > readRef = Lazy.strictToLazyST . readSTRef > writeRef = (Lazy.strictToLazyST .) . writeSTRef > > instance MonadRef (Strict.ST s) (STRef s) where > newRef = newSTRef > readRef = readSTRef > writeRef = writeSTRef For an alternative design, see http://haskell.org/pipermail/libraries/2003-September/001411.html

3 2

RE: Time library discussion (reprise)
by Simon Marlow 13 Nov '03

13 Nov '03

I've now implemented this proposal, modulo the calendar calculations. The implementation is here: http://www.haskell.org/~simonmar/time/NewTime.hsc Compile like so with GHC 6.0.1: $ hsc2hs NewTime.hsc $ ghc -c NewTime.hs The code borrows heavily from the existing System.Time imlementation. Haddock docs here: http://www.haskell.org/~simonmar/time/NewTime.html It's quite possible I've screwed up the implementation somewhere, so please take a look. Examples: *NewTime> t <- getClockTime *NewTime> print t 1068731162437251000000 *NewTime> clockTimeToCalendarTime t >>= print Thu Nov 13 13:45:50 GMT 2003 *NewTime> clockTimeToUTCTime t Thu Nov 13 13:45:50 UTC 2003 *NewTime> clockTimeToTAITime t Thu Nov 13 13:46:02 TAI 2003 see what happens around a leap second: *NewTime> let t = CalendarTime {ctYear=1998, ctMonth=11, ctDay=31, ctHour=23, ctMin=59, ctSec=59, ctPicosec=0, ctTZ=utcTimezone} *NewTime> t Thu Dec 31 23:59:59 UTC 1998 *NewTime> clockTimeToUTCTime (fromJust (calendarTimeToClockTime t)) Thu Dec 31 23:59:59 UTC 1998 forward one second: *NewTime> clockTimeToUTCTime (fromJust (calendarTimeToClockTime t) + 1 * 10^12) Thu Dec 31 23:59:59 UTC 1998 forward 2 seconds: *NewTime> clockTimeToUTCTime (fromJust (calendarTimeToClockTime t) + 2 * 10^12) Fri Jan 1 00:00:00 UTC 1999 Cheers, Simon

1 0

RE: Time library discussion (reprise)
by Graham Klyne 12 Nov '03

12 Nov '03

At 13:34 11/11/03 +0000, Simon Marlow wrote: >Presumably, without TAI support, the library will be unable to do >accurate calendar calculations at the second level (i.e. "add S seconds >to time T"), although it will be able to do larger scale calendar >calculations (i.e. adding days, months, etc.). Or maybe you provide the >second-level calculations but document that they don't take into account >leap seconds? When I raised this, I was thinking of something like: [[ ... you provide the second-level calculations but document that they MAY not take into account leap seconds? ]] I found the reference posted by Peter Simons was helpful. To my mind the stability of representation is more important than stability of operations. Why? In general I feel that representations have greater need of stability. Specific values are written down, maybe find themselves embedded in code, while the results of operations are relatively transient (but this distinction may be contentious in the context of a pure functional language). I noticed this in another of Peter's references: [[ This proposal makes no recommendations for handling leap seconds. Such capabilities are implementationdefined (just as they are in ISO C99). It does, however, allow implementations to support multiple calendric systems; thus an implementation could provide variations of its supported calendric systems that both do and do not handle leap seconds. ]] -- http://david.tribble.com/text/c0xcalendar.html#solutions One other point: Haskell has a significant advantageous difference to C when it comes to time representations of dates and times, viz its Integer type. (I was persuaded by previous discussions that we should not be concerned for its efficiency.) #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Business Mobile Phone Consultancy
by Mobiles 4 Business 11 Nov '03

11 Nov '03

Hi, I was just looking at your web site and saw your email address, I work for a national business to business mobile phone supplier. I supply companies like yours with free consultation regarding your mobile phones, in many cases I can save up to 40% of your mobile phone bills. By simply comparing your current bills with the newest tariffs available I will be able to tell you exactly how much it is possible to save. I will compare all of the mobile networks on your behalf and the service is totally free, if you do decide to change your tariff I can also supply the very latest moiles phones which are normally free of charge, together with free accessories including bluetooth headsets which are totally cordless and compliant with new laws regarding mobile phone usage in cars. If you would like to arrange for a free price comparison you can reach me by emailing me at mobile-phones(a)virgin.co.uk. Many Thanks, James Robinson Mobiles 4 Business

1 0

RE: Time library discussion (reprise)
by Simon Marlow 11 Nov '03

11 Nov '03

> I noted this in the draft communities report: > > [[ > Currently, the discussion has stalled again. The leap seconds > issue is something of a sticking point, and there are some > implementability question marks over other parts of the API. > Contribution to (any aspect of) the discussion is welcomed. > ]] > > As a process meta-issue, I would ask: is there an approach > we can adopt > that allows the concerns about implementability of leap-seconds to be > deferred to a later stage, to the maximum extent possible. > > My simple-minded view is that an approach based on an > underlying value a > pair of values (e.g. days,picoseconds) would allow systems > implemented > without concern for leap seconds to be adequate for a good number of > practical applications. And systems that do know about leap > seconds can do a better job. I don't think this solves the problem (but I might be wrong). We have no problem with doing calculations on TAI time, and doing conversions between TAI and UTC. This has been demonstrated - recently by Juanma Barranquero's library posted to the Haskell list, and I also hacked up a simple TAI library a while ago (though not nearly as complete as Juanma's). The problem is how to get access to TAI time on Unix systems (and indeed other OSs, probably). Unix systems provide something called time_t, which is a timescale that doesn't include leap seconds. Strange things happen on a Unix system when a leap second occurs: the proper way (it seems) to deal with leap seconds is to slow down the system clock a bit until the actual time catches up with time_t again. The point is that if you only have access to time_t, and you don't know what the system is doing with leap seconds, you can't tell what the time is. I'm sure that most people don't care about this (I certainly don't :-). Personally I think it's ok to have a library that "does its best" to give you the correct TAI time, with documented caveats. IIRC, this is where we got stuck. Also, I believe the proposed System.Time library had some functionality which is difficult to implement on Unix systems (eg. a function to convert a timezone name to a GMT offset isn't available AFAIK). Cheers, Simon

2 1

RE: GHC-specific package(s)?
by Simon Marlow 10 Nov '03

10 Nov '03

> How about a package (or packages) for modules that support > experimental > GHC-only language features, like Generics (currently in base) and > Template Haskell (currently in haskell-src)? This would make > it easier > for other implementations to ignore them (they do tend to move around > a bit) and also present a distinction in the library documentation. > (It might even speed up the GHC build a tad, because you > don't need the > rest of haskell-src for stage1.) Sure, I'm happy for these to move out to separate packages. Either a single package ('ghcexts'?) or two packages ('th', 'generics') would be fine. I think I slightly prefer the latter. Cheers, Simon

1 0

Time library discussion (reprise)
by Graham Klyne 09 Nov '03

09 Nov '03

I noted this in the draft communities report: [[ Currently, the discussion has stalled again. The leap seconds issue is something of a sticking point, and there are some implementability question marks over other parts of the API. Contribution to (any aspect of) the discussion is welcomed. ]] As a process meta-issue, I would ask: is there an approach we can adopt that allows the concerns about implementability of leap-seconds to be deferred to a later stage, to the maximum extent possible. My simple-minded view is that an approach based on an underlying value a pair of values (e.g. days,picoseconds) would allow systems implemented without concern for leap seconds to be adequate for a good number of practical applications. And systems that do know about leap seconds can do a better job. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

GHC-specific package(s)?
by Ross Paterson 07 Nov '03

07 Nov '03

How about a package (or packages) for modules that support experimental GHC-only language features, like Generics (currently in base) and Template Haskell (currently in haskell-src)? This would make it easier for other implementations to ignore them (they do tend to move around a bit) and also present a distinction in the library documentation. (It might even speed up the GHC build a tad, because you don't need the rest of haskell-src for stage1.)

1 0