Parsing date and time specifications

[Ketil Z. Malde]

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

>> (My preju^H^Hference would be to store a date-time internally in a
>> posix-like manner (seconds,microsecond since the epoch).)

> I'm still not sure I understand why the Time library is considered to be
> broken

I was probably a bit quick on the trigger there.  Sorry!

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.

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, 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)

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.

Let's sketch a different suggestion.  I haven't given this a lot of
thought, so feel free to shoot it down!

<sketch>
ClockTime -- as is
ClockInterval -- a delta for ClockTimes, diffClockTimes:: CT -> CT -> CI

CalendarTime -- as is, only used as *output* from functions
-- for input, have non-redundant data structures
CalendarDate -- normal, non-redundant date information
CalendarYearDay -- (year, day of year,time)
-- add functions for computing the correct CalendarTime from any of these

CalendarInterval -- a (user constructed) time interval, which allows
                the user to do normal arithmetic (e.g. "add 1 month")
                to CalendarTimes

Notably, ClockIntervals and CalendarIntervals aren't mixable; using
CalendarIntervals (probably?) require locale information, and
converting one into the other (probably) requires a specific reference
point in time. 
</sketch>

Since it's almost Christmas, I'd also like a way to specify things
like "first Tuesday of every month", or "the day before (last Thursday
of every month)".  And a GHC target for my Palm Pilot :-)  We could
build a really cool Cron replacement, and become rich and famous.

(BTW,

> the weekday/yearday in a CalendarTime are ignored by the
> toClockTime in GHC's Time library, so you can set them to anything).

This seems to be standardized behaviour specified in the Report)

Anyway:

Oh well.  I'm not using Time at the moment, so its not an issue that
will ruin my holiday for me :-)  When I have a concrete use for it
that it doesn't support, I'll be sure to let you know! :-)

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