RE: Time library discussion (reprise)
-- | 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
"Simon Marlow"
This is the nub of the problem: the proposal does provide such functionality, but it isn't implementable on Unix systems.
..but it is, for times where leap second information is available (and where the underlying behavior is known)?
I think you're assuming that the timezone TLAs don't represent fixed offsets relative to UTC. I assume that they do.
Yes. I've tried to check, but I don't find any handy references by superflous googling.
For example, here we are in timezone GMT at the moment (== UTC+0000), but we switch to BST in the summer (UTC+0100).
It appears you're right: sefirot% date Thu Nov 13 11:39:19 CET 2003 sefirot% date 07011000 date: cannot set date: Operation not permitted Tue Jul 1 10:00:00 CEST 2003
I just looked up the list of timezone abbreviations, and it's pretty short. The library could easily include this list.
data Timezone = UTC | GMT | PDT ... deriving ... data TZOffset = -- abstract (or just an Int)
Not sure what this would buy us.
Reversibility? I was assuming that there was, perhaps, a one-to-many relationship between names and offsets. Apparently this is wrong, and the three/four-letter abbreviations are just a more complex way to say Alpha, Bravo ... Zulu time (or +0100, -0100, +0200...).
Yes, but don't confuse geographical locations with timezones.
Okay. It seems I was mistaken about this. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
On Thu, 2003-11-13 at 02:16, Simon Marlow wrote:
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.
Where did you find this list? With a little Google searching I found several conflicting sources: http://www.weltzeituhr.com/laender/zeitzonen_e.shtml has MANY meanings for some TLA's: (AST could be Al Manamah, Anguilla, Antigua, Antilles, Arabia, Arabic, or Atlantic Standard Time; or Asia Time). Brazil is listed has having BRT for Brasilia Time (for the middle and east) or for Brasil Time (for the south) or BRST for the south "Summer Time". http://home-4.tiscali.nl/~t876506/Multizones.html lists for Brazil "Atlantic time", "Central Brazil time", "Amazone time", and "Acre time", with no mentioned abbreviations. http://www.mhonarc.org/MHonArc/doc/resources/timezones.html says that BST is British Summer, and that BZT2 is Brazil Zone 2 (no mention of other Brazil zones); but mentions at the bottom that BST may also be Brazil Standard. http://www.cryst.bbk.ac.uk/listproc/vsns-pps-technical/9501/0031.html lists information retrieved from SysVR4 timezone files; here, EST could mean Canada/Eastern or US/Eastern (-5:00), Brazil/East (-3:00), Chile/EasterIsland (-6:00), or Australia/Tasmania (+10:00). The data which is currently "authoritative", at least for Linux (the ultimate source for the files in my /usr/share/zoneinfo directory), is the tzdata package from ftp://elsie.nci.nih.gov/pub/. The latest version (as of this writing), tzdata2003d.tar.gz, is less ambiguous than the SysVR4 data, but still contains ambiguities (a quick check reveals EST for Australia (+10:00) and the US (-5:00); there's actually some discussion of the issue, in the file "australasia", which mentions IST: Israel Standard Time (+2:00), India Standard Time (+5:30), Irish Summer Time).
Perhaps we want a way to map geographical locations to timezones.
Ooh, dangerous. Microsoft took its cool timezone world map out of post-Windows 95 (I think) editions because of political issues: some territory was disputed between two countries, who wanted to apply different timezones to the territory; so Microsoft's map was seen as endorsing one country as the "correct" owner of the territory. (I don't remember the details.) Would you have, like tzdata does, a separate "time zone" for Boise, Idaho? Boise is in Mountain time; but, according to tzdata, it switched into or out of daylight savings time four weeks late in 1974 (I was there at the time, but I was only 5, so I don't remember), so it's listed separately (in case somebody wants to know what the local time would have been in 1974, I guess). I recommend reading through the files in tzdata for a LOT of interesting time zone anecdotes (things like "Shanks partitions Indiana into 345 regions, each with its own time history, and writes ``Even newspaper reports present contradictory information.''" and "I know one story of a town on one time zone having its school in another, such that a mom had to serve her family lunch in two shifts." Carl Witty
At 12:31 13/11/03 -0800, Carl Witty wrote:
I just looked up the list of timezone abbreviations, and it's pretty short. The library could easily include this list.
Where did you find this list? With a little Google searching I found several conflicting sources:
FWIW, a widely respected source is the Olson database, at: ftp://elsie.nci.nih.gov/pub/ Ah, I see you mention that too: [[ The data which is currently "authoritative", at least for Linux (the ultimate source for the files in my /usr/share/zoneinfo directory), is the tzdata package from ftp://elsie.nci.nih.gov/pub/. ]] This is cited by RFC2445 (iCalendar), and was frequently mentioned in the old IETF calendaring/scheduling discussions that I reviewed some time ago. But in the end it proved to be a somewhat intractable topic, which is why we went for the cut down time-and-date format specification in RFC 3339. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
participants (4)
-
Carl Witty -
Graham Klyne -
ketil+haskell＠ii.uib.no -
Simon Marlow