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