Parsing date and time specifications

Ketil Z Malde ketil@ii.uib.no
26 Dec 2002 18:48:05 +0100


"Simon Marlow" <simonmar@microsoft.com> writes:

> That may well be true, and I've heard others suggest that the library is
> inconvenient.  I'm trying to get at whether that is due to current bugs
> in the implementation, or whether the design is fundamentally broken.

Well; perhaps the right thing to do is to implement a rich cron
replacement and perhaps other calendar-using functions, and see what
we need for that? 

>> non-consistent CalendarTimes,

> Ok, I don't consider that to be a problem.  The toClockTime operation
> should fail if the CalendarTime is inconsistent.  

I'm on a piece of string, so I didn't check, but I think GHC and the
spec says it just ignores redundant parts?

>> and there are multiple ways
>> to represent the same interval as TimeDiff -- in fact, two TimeDiffs
>> may or may not be equal, depending on what CalendarTime they apply
>> to.  (The 'deriving' of Eq makes this a moot point, perhaps, but
>> seems to make equality rather non-intuitive)

> I think this is the wrong way to look at it: two TimeDiffs should be
> equal if and only if all their components are respectively equal (i.e.
> the deriving Eq meaning).

Okay.  This loses a lot of nice algebraic properties, but perhaps
that's unavoidable.

> And another thing: it should be specified that diffClockTimes gives a
> TimeDiff in units of seconds & picoseconds, because these are the only
> forms of TimeDiff that have the same meaning independent of what
> ClockTime they are added to.
  [...]
> I think TimeDiffs are deltas for ClockTimes only.  Why do you say they
> are intervals of calendar times too?

Well, they do have fields for days, months etc.  From their
definition, it seems reasonable to use them in that way.

If the two concepts are separate, I think it makes more sense to have
TimeDiff contain only s/ps fields, and have a CalendarDiff convertible
to a TimeDiff, given a specific CalendarTime.  Or something.

But the whole thing seems a bit Pascallish to me.  Why no generating
functions and combinators for all dates, all Fridays, all second
Tuesdays of months starting with 'J'?  Where's the Functional Spirit? 

:-)

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