Bayley, Alistair wrote:
From: Ashley Yakeley [mailto:ashley@semantic.org]
* Should we include a timezone field in CalendarTime?
Yes. If a CalendarTime doesn't carry timezone information with it, then the user must bundle it. They will want to do this because (1) they will be probably dealing with local time (2) a CalendarTime sans timezone is equivalent to UTC, and is therefore not much use (i.e. we may as well use UTC instead).
* TimeZone represents a fixed offset to UTC. What should it look like internally, and what functions on it should we provide?
There are timezones which are not integral hour offsets, so an (hours, minutes) pair, or maybe just ticks is sufficient. Or maybe a Duration (see below). Ticks is probably best from an implementation point-of-view, right?
For example, New Delhi is on the half hour when time here is on the hour. I'm not sure whether that is part of a daylight savings scheme or not. Certainly ticks has the granularity to represent any fixed offset.
Should it include the timezone name? Although the name determines the offset, a given offset could match many names, so to preserve information we'd probably want to retain the timezone name internally. Do we want to support timezone names?
Do we want to embed summer-time (daylight-savings) timezone behaviour into the library? This would obviously be useful for displaying the correct local time, but makes the timezone part of the library quite complex.
There are many details which are not easy to represent with a timezone. There are places (e.g. in Indiana) where a town just over the timezone line from another town uses the "wrong" timezone, in that case to handle the problem that the towns have grown to the point where they are actually one (virtual?) town. Arizona does not observe daylight savings time, but on some of the Indian reservations daylight savings is observed. The state of Sonora, in Mexico, makes a decision periodically to follow, or not follow, the fact that Arizona (its northern neighbor) doesn't use daylight savings, but other Mexican states in the same time zone do observe daylight savings. In the last ten years I know that the decision has changed twice, and currently Sonora follows the practice of other Mexican states in the same time zone. So, a time zone, at least one based on geographical location, isn't sufficient. Accounting for daylight savings doesn't cover every case either; I gave a couple of examples but doubtless there are many others I don't know about. You can still represent them in terms of an offset, but your information becomes stale, and the time zone name, or the time returned by localtime, isn't necessarily the local time. (A bizarre but true statement). Most operating systems, at least as delivered, don't have any way to handle variations other than daylight savings. There is no way to override the boundaries of a time zone. In most cases you could correct this by adding a new time zone, but I wouldn't want to try this in windows. I think the only way to handle it is with an argument that allows the user to override the offset that the machine itself uses. That's ugly, and you would have Haskell returning a different time than the localtime() library call. You can argue that it is better to be accurate, but you can also argue that issues will arise. A program might be using FFI and thus one part of the program potentially would have a different value for the local time than another part. Also it is an invitation to make a mistake, by either forgetting to use the signature that allows application of a user correction, or not using the same offset for each call. All the possible solutions are (IMHO) unacceptable. So I guess you have to choose which is the least unacceptable.
OK, so here are the basic functions of System.Time.Calendar:
utcToCalendar :: TimeZone -> UTCTime -> CalendarTime
calendarToUTC :: TimeZone -> CalendarTime -> UTCTime
CalendarTime should be a "struct", i.e. a datatype with its constructor and access functions exported.
I'm assuming System.Time.Calendar is Gregorian. How about - a Duration type - some calendar arithmetic functions - arithmetic on Durations
e.g.
data Duration = Duration { -- this looks familiar... durYear :: Int, durMonth :: Int, durDay :: Int, durHour :: Int, durMin :: Int, durSec :: Int, durPicosec :: Integer } deriving ...
calendarAdd :: CalendarTime -> Duration -> CalendarTime calendarDiff :: CalendarTime -> CalendarTime -> Duration durationAdd :: Duration -> Duration -> Duration durationDiff :: Duration -> Duration -> Duration
Alistair.
----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
!DSPAM:42108ad5163345519714160!