In article <20060206124958.GE4514@soi.city.ac.uk>, Ross Paterson wrote:

On Mon, Feb 06, 2006 at 12:00:44AM -0800, Ashley Yakeley wrote:

...

Please take a look at my third draft of a replacement for the standard time library. http://semantic.org/TimeLib/

It looks very clean.

Thank you. This was a design goal.

One oddity I noted was that the Gregorian counterparts of the functions in Data.Time.Calendar.Julian are split between Data.Time.Calendar and Data.Time.Calendar.OrdinalDate, the latter having different names. Data.Time.Calendar.Gregorian? Then someone will want you to take Julian and Gregorian out of the function names, I suppose.

Julian calendar functions are likely to be rarely used, so I put that in a second-level module as part of my scheme to keep the common stuff in Data.Time.* and the less common stuff in Data.Time.*.*.

You might want to throw in Julian versions of the startWeek functions for completeness.

I may do this. I may also promote isLeapYear from .Calendar.OrdinalDate to .Calendar if it doesn't screw up the dependencies too much (.Calendar.Gregorian exists but is hidden: it depends on .Calendar.OrdinalDate). I suppose I could have isLeapYear in both.

There's also the question of replacing some tuples by records.

OK, currently we have this: toGregorian :: Day -> (Integer, Int, Int) fromGregorian :: Integer -> Int -> Int -> Day -- clips to ranges In version 0.1 I had a record type instead: data GregorianDay = MkGregorianDay { gregorianYear :: Integer, gregorianMonth :: Int, gregorianDay :: Day } This is a completely new type that is almost, but not quite, isomorphic to Day. As such, I made it an instance of most of the same classes as Day. It isn't quite isomorphic, however, since it allows invalid days, and these needed to be dealt with in all the code that used it. And it doesn't actually gain us anything. The useful parts of GregorianDay are the constructor and the access functions, not the type itself, and it's easier to do that with functions on Day. I had a class for types such as GregorianDay that were isomorphic to Day. It just confused people.

Might the Clock and LocalTime modules belong under System?

Not the whole modules, no, I'd rather keep the pure calculation under Data. There might be a case for putting the FFI-using functions under System (getCurrentTime, getPOSIXTime, getTimeZone, getCurrentTimeZone, getZonedTime, utcToLocalZonedTime) since they all call system functions, but we'd have to pick a module name. I'll only do it if a lot of people think it's a good idea, otherwise I'm happy with keeping everything under Data.Time. -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/

In article <43E74BF0.6090708@microsoft.com>, Simon Marlow wrote:

Ashley Yakeley wrote:

...

Please take a look at my third draft of a replacement for the standard time library. http://semantic.org/TimeLib/

Take a look at the Haddock documentation: http://semantic.org/TimeLib/doc/html/

The changes look really good, nice work!

Thanks!

I propose swapping out the Data.Time library with this one in GHC 6.6, leaving the old one available as "Time" (in the haskell98 package). Also, I'm going to propose it for inclusion in Haskell'.

Should I create a new package as http://darcs.haskell.org/packages/time ? The source is already in a darcs repository, but it might not be arranged in the right way.

I think the documentation would benefit greatly from a list of examples (as has been mentioned before). Anyone like to do this?

I'm not sure of the best way to publish these. Should they just appear in the haddock? -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/

In article <91951618304.20060213182803@HotPOP.com>, Bulat Ziganshin wrote:

AY> Please take a look at my third draft of a replacement for the standard AY> time library. AY> http://semantic.org/TimeLib/

afai understand, your library should replace "getClockTime" functionality, but it's not obvious what function what function one should use. how i can

1) print difference between two wallclock times in form "Elapsed 3.024 seconds"

do t0 <- getCurrentTime foo t1 <- getCurrentTime putStrLn ("Elapsed " ++ (show (diffUTCTime t1 t0)) ++ " seconds") Of course, this will be off if the clock has had a leap-second step in between.

2) convert CTime (returned by stat() function) to the ClockTime analog and back. May be that is not intended use of your library, but i does it in order to "touch" files and print file's datetime stamp in the human-readable form

import Data.Time.Clock.POSIX type Time_t = Integer fromTimeStamp :: Time_t -> UTCTime fromTimeStamp = posixSecondsToUTCTime . fromInteger toTimeStamp :: UTCTime -> Time_t toTimeStamp = truncate . utcTimeToPOSIXSeconds

at the current moment your library really omits docs. that you have is comments to functions, why docs should be task-oriented

I have some use-cases here: http://semantic.org/TimeLib/TimeLib/time/test/UseCases.lhs -- Ashley Yakeley, Seattle WA WWED? http://www.cs.utexas.edu/users/EWD/