I finally took a look at the earlier discussions, and find that I stand by the broad view I expressed before [1]. I think it is not the role of a "standard library" to be all applications, but rather that it should aim to provide functionality that is useful to a wide range of applications. Specialized applications are, well, special, and their raison d'etre is to embody specialized domain knowledge in executable form, while a general purpose language and libraries aims to provide the means for expressing such embodiment. (This may be a simplification, but I think the principle is fair.) In particular, I think that calendar based scheduling (6:00PM local time on the second Thursday of every month) is a specialized, if widely used, kind of application. I don't think the common library should be trying to support such functionality, if only because whatever semantics you choose, you can be pretty certain it will be wrong for a signifcant number of would-be users. What the standard library *can* do is provide tools that specialized applications can use: for example, functions to convert between Gregorian calendar dates and Julian dates are well-defined, and can make a range of other, more specialized functions much easier to code. In a similar vein, I think it's quite usual for people and applications to deal with a day as a consistent time interval without concern for possible leap seconds, so dealing with days as intervals of 24*60*60 seconds is useful for a majority of applications that deal with such intervals. Thus, allowing intervals to be expressed using days and sub-intervals, or seconds and sub-intervals have roles in a supporting framework that can be used by a variety of applications. In any redesign, I would suggest dropping the redundant day-of-year and day-of-week values, replacing them with functions. I assume there's no burning need for a redesign of this. There should come a time, hopefully not too far away, when I'll be designing Haskell support for aspects of RFC 2445-based calendar information expressed in RDF [2]. That would probably be a good time for me to consider a concrete design and implementation. If there's consensus on a design, I think the only tricky part of its implementation will be a dependable Gregorian/Julian date conversion function, and I expect that already exists. #g -- [1] http://haskell.cs.yale.edu/pipermail/libraries/2003-June/001095.html [2] http://www.w3.org/2002/12/cal/ At 14:08 02/06/03 +0200, Ketil Z. Malde wrote:

"Simon Peyton-Jones" writes:

...

...

I understand there's some history here, of which I'm not properly aware, so if this is merely rehashing old ground, please ignore.

As someone who got entangled in this last time it was discussed (and the time before that), I can inform you that it has indeed been discussed a bit, and that you could probably search the archives profitably for ideas and thoughts on the matter.

http://www.haskell.org/pipermail/haskell/2002-January/008678.html

and (same thread, but broken up, due to broken mail headers):

http://www.haskell.org/pipermail/haskell-cafe/2002-December/003742.html http://www.haskell.org/pipermail/haskell-cafe/2002-December/003751.html http://www.haskell.org/pipermail/haskell-cafe/2002-December/003758.html

...

Rather than try to fix it incrementally, I think it'd be most productive if the interested parties simply got together and agreed an interface for a new Time module, even if it's incompatible with the old one.

Yes, definitely. Useful time/data module is probably best designed by somebody who actually *have* use for it.

-kzm -- If I haven't seen further, it is by standing in the footprints of giants

------------------- Graham Klyne PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

Dylan Thurston writes: : | What about the fact that days are not actually intervals of 24*60*60 | seconds (as I'm sure you know)? Most applications don't care, but | it's crucial to give correct and unsurprising results. : Some applications surreptitiously use sixtieths of minutes instead of seconds. :-)