- Libraries - Haskell.org

RE: Calendar Types
by Bayley, Alistair 15 Feb '05

15 Feb '05

> From: Ashley Yakeley [mailto:ashley@semantic.org] > > * Should we include a timezone field in CalendarTime? Yes. If a CalendarTime doesn't carry timezone information with it, then the user must bundle it. They will want to do this because (1) they will be probably dealing with local time (2) a CalendarTime sans timezone is equivalent to UTC, and is therefore not much use (i.e. we may as well use UTC instead). > * TimeZone represents a fixed offset to UTC. What should it look like > internally, and what functions on it should we provide? There are timezones which are not integral hour offsets, so an (hours, minutes) pair, or maybe just ticks is sufficient. Or maybe a Duration (see below). Ticks is probably best from an implementation point-of-view, right? Should it include the timezone name? Although the name determines the offset, a given offset could match many names, so to preserve information we'd probably want to retain the timezone name internally. Do we want to support timezone names? Do we want to embed summer-time (daylight-savings) timezone behaviour into the library? This would obviously be useful for displaying the correct local time, but makes the timezone part of the library quite complex. > OK, so here are the basic functions of System.Time.Calendar: > > utcToCalendar :: TimeZone -> UTCTime -> CalendarTime > > calendarToUTC :: TimeZone -> CalendarTime -> UTCTime > > CalendarTime should be a "struct", i.e. a datatype with its > constructor and access functions exported. I'm assuming System.Time.Calendar is Gregorian. How about - a Duration type - some calendar arithmetic functions - arithmetic on Durations e.g. data Duration = Duration { -- this looks familiar... durYear :: Int, durMonth :: Int, durDay :: Int, durHour :: Int, durMin :: Int, durSec :: Int, durPicosec :: Integer } deriving ... calendarAdd :: CalendarTime -> Duration -> CalendarTime calendarDiff :: CalendarTime -> CalendarTime -> Duration durationAdd :: Duration -> Duration -> Duration durationDiff :: Duration -> Duration -> Duration 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. *****************************************************************

9 16

RE: Calendar Types
by Bayley, Alistair 15 Feb '05

15 Feb '05

> From: Keean Schupke [mailto:k.schupke@imperial.ac.uk] > > This in IMHO is much better than windows > broken system of actualy moving the clock forwards and back for > daylight-savings. Do they still do that? (I do recall a big fuss over Win95 doing that, and how impressed people were that the system was so *clever*.) I just assumed that MS got it right later on - or didn't they? ----------------------------------------- ***************************************************************** 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

Time Libraries Rough Draft
by Ashley Yakeley 15 Feb '05

15 Feb '05

This seems to be roughly where we're at with the time libraries. It's now three modules, Clock, LeapSeconds, and Calendar. Most people will have no need for LeapSeconds. I've added two more things which haven't been discussed much. The first is a getCPUTime function that returns the current "CPU time". This has an arbitrary base, but it doesn't hiccup. The Unix interface for this is a "clock()" function that returns time in some unit, and CLOCKS_PER_SECOND, which is a constant to convert to seconds. I'm assuming there's a Windows equivalent to this. The second thing is a type-synonym of Rational for Julian dates. Julian dates are a standard representation of UT1, where one unit is one day, and UT1 is a good choice for representing Earth-based times in the far past or future continuously. System.Time.Clock: * UTC arithmetic * types or type-synonyms for Julian days and dates (for UT1) * getting the current UTC time * getting the current "CPU time" System.Time.LeapSeconds: * TAI arithmetic * leap-second table type * conversion between UTC and TAI with table System.Time.Calendar (largely undiscussed so far): * time zones * getting the locale time zone * converting times to Gregorian "calendrical" format * 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, interface to zoneinfo database * calendar systems other than Gregorian * generalised sets over time e.g. "2pm-4pm every 4th Saturday of the month" module System.Time.Clock ( ... ) where -- | standard Julian count of Earth days type JulianDay = Integer newtype DiffTime = MkDiffTime Integer timeToSISeconds :: DiffTime -> Rational siSecondsToTime :: Rational -> DiffTime data UTCTime = MkUTCTime JulianDay DiffTime newtype UTCDiffTime = MkUTCDiffTime Integer utcTimeToUTCSeconds :: UTCDiffTime -> Rational utcSecondsToUTCTime :: Rational -> UTCDiffTime addUTCTime :: UTCDiffTime -> UTCTime -> UTCTime diffUTCTime :: UTCTime -> UTCTime -> UTCDiffTime ...more arithmetic on UTCDiffTime... -- | standard Julian dates for UT1, 1 = 1 day type JulianDate = Rational getCurrentTime :: IO UTCTime getCPUTime :: IO DiffTime -- | most people won't need this module module System.Time.LeapSeconds ( ... ) where -- | TAI type AbsoluteTime = MkAbsoluteTime Integer addAbsoluteTime :: DiffTime -> AbsoluteTime -> AbsoluteTime diffAbsoluteTime :: AbsoluteTime -> AbsoluteTime -> DiffTime -- | TAI - UTC during this day type LeapSecondTable = JulianDay -> Int utcDayLength :: LeapSecondTable -> JulianDay -> DiffTime utcToTAITime :: LeapSecondTable -> UTCTime -> TAITime taiToUTCTime :: LeapSecondTable -> TAITime -> UTCTime module System.Time.Calendar ... TBD ... -- Ashley Yakeley, Seattle WA

8 17

fptools build for 'arrows' package
by Peter Simons 15 Feb '05

15 Feb '05

I've attached the necessary files so that libraries/arrows can be built (and installed) as part of GHC. It would be nice if someone with CVS commit rights could add those (and add "arrows" to libraries/Makefile). Peter

2 1

RE: Calendar Types
by Bayley, Alistair 15 Feb '05

15 Feb '05

> From: Ketil Malde [mailto:ketil+haskell@ii.uib.no] > > You also need to specify, or let the user specify, the order of > arithmetic. I.e. adding a day and then a second is different from > doing it the other way around. Duration arithmetic is not commutative? Can you give some examples please, because I'm not able to imagine any. ----------------------------------------- ***************************************************************** 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 6

A bunch of new libraries ...
by Peter Simons 14 Feb '05

14 Feb '05

... or new versions of "old" libraries are available here: http://cryp.to/blockio http://cryp.to/child http://cryp.to/formdata http://cryp.to/funcmp http://cryp.to/hopenssl http://cryp.to/hsdns http://cryp.to/hsemail http://cryp.to/monadenv http://cryp.to/streamproc Each of those URLs hosts a darcs repository, all modules come with *.cabal files and build instructions for fptools; so if you compile GHC from the source code you can just drop them in at libraries/xxxx, edit libraries/Makefile, and then they'll be built as part of the standard libraries. For browsing the documentation and figuring out what is what, this URL is probably the best choice because it shows documentation for all of them: http://postmaster.cryp.to/docs/index.html Feedback is welcome, as always. Peter

1 0

RE: Text.Regex.Posix exposes too little
by Simon Marlow 14 Feb '05

14 Feb '05

On 11 February 2005 21:24, Peter Simons wrote: > I was wondering why Text.Regex.Posix does not expose the Ptr > interface to the regular expression library? Is there a > deeper reason for that? No deep reason that I'm aware of. > I am also worried about the fact that the module uses > finalizers to free-up unused expressions -- rather than > providing a bracket-style > > withRegex :: String -> Int -> (Regex -> IO a) -> IO a > > function. We quite often use it with a regex defined at the top-level: r = mkRegex "..." f x = case matchRegex r x of ... Although in this case there is limited benefit from having the regex garbage collected, since there can only be a bounded, probably small, number of these in the program. Providing withRegex seems like a good idea, though. > Last but not least I see that the regex flags are > represented as an 'Int'. I don't feel strongly about this, > but IMHO a > > data RegexFlag = IgnoreCase > | Newline > | ... > > data type with an appropriate declaration for Enum would be > nicer for this purpose. > > Unless there is violent opposition, I'd volunteer to make > those changes, because as it happens I need them anyway. ;-) Please go ahead, I'll review and commit your patch. Cheers, Simon

1 0

RE: Time Libraries Rough Draft
by Simon Marlow 14 Feb '05

14 Feb '05

On 10 February 2005 12:12, Marcin 'Qrczak' Kowalczyk wrote: > Seth Kurtzberg <seth(a)cql.com> writes: > >> The simple fact that UTC time is not monotonically increasing causes >> a whole host of difficulties. > > And the simple fact that obtaining TAI from systems in use requires > periodic updates of the leap second table causes other difficulties. This is a vitally important bit of rationale which has emerged from the current discussion. I certainly didn't fully appreciate the difficulties with basing the library on TAI before, and I imagine others won't too. I think it's important that we clearly state this rationale in the docs for the new library. Cheers, Simon

13 23

RE: registration tricks (cabal)
by Simon Marlow 14 Feb '05

14 Feb '05

On 14 February 2005 03:02, Isaac Jones wrote: > So I'm thinking of adding a flag to register and unregister, maybe > --dry-run or something which does _not_ register right away, but > rather emits such a script. This is actually a pretty small change, > but I wanted to check with you folks before adding it, since we're so > close to a release. > > Does anyone see any problems with this? Seems reasonable to me. You might want to make the script self-contained, though, i.e. have it actually include the contents of .installed-pkg-conf to avoid the complication of having a separate file which you have to locate. Cheers, Simon

1 0

Re: Time Libraries Rough Draft
by Udo Stenzel 14 Feb '05

14 Feb '05

Ashley Yakeley <ashley(a)semantic.org> schrieb am 11.02.05 21:39:42: > > The most obvious functions in Calendar are going to be these: > > utcToCalendar :: TimeZone -> UTCTime -> CalendarTime > calendarToUTC :: TimeZone -> CalendarTime -> UTCTime And what would you do with the "UTCTime", whatever that is? You can't do arithmetic on it, because that is full of surprises, not only around leap seconds, but also around leap hours and days. You can only store it and read it back, but that can already be done with the CalendarTime itself. I think, the most useful operations are those that "roll" the calendar fields, say to advance by a day (which is not always 24 hours long). Converting a CalendarTime to a number of seconds is just useless, the apparent simplification only introduces complications. Udo. ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

3 2