Parsing date and time specifications

[Simon Marlow]

> I was probably a bit quick on the trigger there.  Sorry!
>=20
> It't been a while since I tried using CalendarTime and friends; I did
> have some difficulty making things fit, and eventually gave up the
> whole thing.  My impression (which may well be a wrong one) was that
> others also had trouble adapting the library to their uses, too, and
> that the Time library was one of the less successful ones.

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.

> Looking at it now, possible criticisms could arise from the data types
> containing redundancy and non-uniqueness: e.g. one can easily
> construct non-consistent CalendarTimes,

Ok, I don't consider that to be a problem.  The toClockTime operation
should fail if the CalendarTime is inconsistent.  Non-uniqueness isn't a
problem: you can convert to a ClockTime which is unique.  I think of the
CalendarTime as a slightly more tractable representation of a date/time
string; lots of date strings don't make sense either (eg. "31
February").

> 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).  This is different from saying that "the
effect of adding this TimeDiff is the same as adding this other
TimeDiff", which depends entirely on what you're adding it to.  So this
cannot lead to a sensible meaning for Eq on TimeDiff.

Ah - I've just realised one problem with the design.  If you have a
TimeDiff with multiple non-zero components (eg. one hour and one
second), then the order in which you add them makes a difference, and
this order isn't specified by the spec.  That's probably why TimeExts
has only single-unit differences.

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.

> It seems that TimeDiffs perform two functions; deltas for ClockTimes
> (in the functions) and intervals of calendar times (specification of
> the data type), and I'm not sure it's a good idea to mix those.

I think TimeDiffs are deltas for ClockTimes only.  Why do you say they
are intervals of calendar times too?

If we were to have an operation which adds a TimeDiff to a CalendarTime,
then its meaning should be the same as converting the CalendarTime to a
ClockTime, adding the TimeDiff, and converting back to a CalendarTime
again.

> Oh well.  I'm not using Time at the moment, so its not an issue that
> will ruin my holiday for me :-)

me either :)=20

Cheers,
	Simon