seth at cql.com
Tue Feb 15 00:01:47 EST 2005
Keean Schupke wrote:
> Seth Kurtzberg wrote:
>> 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.
> Historically, towns in the UK used to have their own time (set by
> midday) - however when the railway came, it was necessary to
> standardise time, so that train timetables could be compiled.
> What do the national train/public-transport services do in these
> instances? My gut feeling would be that whatever they do would be what
> Haskell should do. I would guess that such local anomalies are ignored
> by the public transport timetables?
The same history applies here, and both rail and air travel use the
"official" time of their geographic location. It's probably the least
confusing way to do it, but it's hard to choose among ugly solutions.
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries