seth at cql.com
Mon Feb 14 16:01:09 EST 2005
Bayley, Alistair wrote:
>>From: Ashley Yakeley [mailto:ashley at 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
>>* 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
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
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
> 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
>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 at haskell.org
More information about the Libraries