Concerning Time.TimeDiff

[Graham Klyne]

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" <simonpj@microsoft.com> 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
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E