> > -- | A representation of absolute time, measured as
> picoseconds since
> > -- the epoch, where the epoch is 1 January 1970 00:10 TAI.
> > data ClockTime -- abstract
> > instance of (Eq, Ord, Num, Enum, Integral, Show, Read)
> >
> > -- | returns the current absolute time
> > getClockTime :: IO ClockTime
>
> The advantage (what I tried to say in my previous message) is that
> something like
>
> t1 <- getClockTime
> :
> t2 <- getClockTime
> print ("Elapsed time: "++ show (t2-t1)++" seconds")
>
> would work correctly, and not just work "most of the time", like it
> would with UTC.
This is the nub of the problem: the proposal does provide such
functionality, but it isn't implementable on Unix systems.
> > data Timezone -- abstract
>
> > -- | Make a 'Timezone' from an offset, in seconds relative to UTC,
> > -- which must be smaller in magnitude than @+/-12*60*60@.
> > timezoneFromUTCOffset :: Int -> Timezone
>
> Don't you also need a specific time? We have UTC+0100 in the winter,
> but +0200 in summer (or was it the other way around? :-)
>
> Perhaps we should separate between Timezones (the TLAs) and their
> offsets. We could have a
>
> localTime :: Timezone -> ClockTime -> CalendarTime
>
> and make the offset, but not TZ, a part of CalendarTime. Would it
> then make (more) sense to compare CalendarTimes? At least it wouldn't
> need to involve timezone tables.
I think you're assuming that the timezone TLAs don't represent fixed
offsets relative to UTC. I assume that they do.
For example, here we are in timezone GMT at the moment (== UTC+0000),
but we switch to BST in the summer (UTC+0100).
I just looked up the list of timezone abbreviations, and it's pretty
short. The library could easily include this list.
Isn't your localTime above exactly the same as
'clockTimeToCalendarTimeTZ' in the proposal?
> data Timezone = UTC | GMT | PDT ... deriving ...
>
> data TZOffset = -- abstract (or just an Int)
> instance Num TZOffset -- auto conversion from int, etc
> tzToOffset :: Timezone -> TZOffset
Not sure what this would buy us.
> > TODO: add isDSTCalendarTime? (returns True if the specified
> > CalendarTime is in daylight savings). How do we say "what's the
> > current timezone in X", taking into account DST?
>
> Exactly.
Yes, but don't confuse geographical locations with timezones. A given
geographical location can be in one of several timezones, depending on
the ClockTime.
Perhaps we want a way to map geographical locations to timezones. You
can do this in Unix (sort of), like this:
$ TZ=America/New_York date
Thu Nov 13 05:07:26 EST 2003
i.e. New York is currently in the EST timezone.
> > - Need to define the meaning when the offset doesn't exist.
> > eg. adding a day at the end of the month clearly rolls over
> > into the next month. But what about adding a month to
> > January 31st?
>
> Perhaps it would be possible to have a more flexible system, where one
> could specify things like the last day of the month, the second
> Wednesday every second month, and so on? Not sure how it would look,
> though.
Sure, but let's get the basics right first :-)
Cheers,
Simon
