In article <87u0ofnzz8.fsf@sefirot.ii.uib.no>, Ketil Malde wrote:

...

Yes. If a CalendarTime doesn't carry timezone information with it, then the user must bundle it.

It would also be nice to provide (at least a framework) for non-Gregorian calendars (e.g. thirteen months).

I was thinking that CalendarTime would work for both Gregorian and Julian calendars, but people would create their own types for other calendars. -- Ashley Yakeley, Seattle WA

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.

Keean. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

!DSPAM:42111817210961851815633!

Seth Kurtzberg writes:

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.

Linux (glibc) tries to provide that information. It has lots of rules even for weird timezones.

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.

It's fine to be able to override, but the default should definitely be taken from the OS. It is possible to discover the offset which should be used for the given timestamp, but it's clumsy: do localtime() and gmtime(), and subtract the results: diff = (((loc.tm_wday - gm.tm_wday) * 24 + (loc.tm_hour - gm.tm_hour)) * 60 + (loc.tm_min - gm.tm_min)) * 60 + (loc.tm_sec - gm.tm_sec); if (diff < -302400) diff += 604800; else if (diff >= 302400) diff -= 604800; Linux has tm_gmtoff, it can be used instead if it's available - it's not portable. You will not know which part of the difference is due to geographical location and which is due to DST, but usually it doesn't matter. You can only know whether DST is in effect or not: tm_isdst. When converting in the other direction, from broken-down time to timestamp, sometimes the DST is not known, yet its useful to guess it, even though one hour in a year is ambiguous and another is impossible. Libc can be used for that: call mktime() with tm_isdst less than 0, and then either use tm_gmtoff or call gmtime() and subtract the results as before. If the year is outside the range supported by libc, I'm afraid there is no OS-provided way to take DST into account, at least on Linux. You can sometimes infer the geographical timezone: call tzset() and use variable 'extern long timezone;', if it exists and has the correct type - it's not portable. Note: it has the opposite sign to tm_gmtoff. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

Marcin 'Qrczak' Kowalczyk wrote:

Seth Kurtzberg writes:

...

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.

Linux (glibc) tries to provide that information. It has lots of rules even for weird timezones.

...

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.

It's fine to be able to override, but the default should definitely be taken from the OS.

It is possible to discover the offset which should be used for the given timestamp, but it's clumsy: do localtime() and gmtime(), and subtract the results:

diff = (((loc.tm_wday - gm.tm_wday) * 24 + (loc.tm_hour - gm.tm_hour)) * 60 + (loc.tm_min - gm.tm_min)) * 60 + (loc.tm_sec - gm.tm_sec); if (diff < -302400) diff += 604800; else if (diff >= 302400) diff -= 604800;

Linux has tm_gmtoff, it can be used instead if it's available - it's not portable.

You will not know which part of the difference is due to geographical location and which is due to DST, but usually it doesn't matter. You can only know whether DST is in effect or not: tm_isdst.

When converting in the other direction, from broken-down time to timestamp, sometimes the DST is not known, yet its useful to guess it, even though one hour in a year is ambiguous and another is impossible. Libc can be used for that: call mktime() with tm_isdst less than 0, and then either use tm_gmtoff or call gmtime() and subtract the results as before.

If the year is outside the range supported by libc, I'm afraid there is no OS-provided way to take DST into account, at least on Linux. You can sometimes infer the geographical timezone: call tzset() and use variable 'extern long timezone;', if it exists and has the correct type - it's not portable. Note: it has the opposite sign to tm_gmtoff.

True, it isn't portable, but no solution is portable. So you either don't handle it, or handle it in a similar way to what you suggest. Thinking about it, the time zone issue should be separated from this library, for the same reasons that it has been argued that a leap second table should be separate. And, as has been suggested for the leap second dilemma, you can use the functions in the low level library and enhance them for leap seconds, time zones, or whichever other variations that come up. One thing that this thread has emphasized is that working with time is complicated. I've been converted to the view of others in the thread that time library under discussion should handle the functions whose behavior is clear, and handle the things that are more controversial, or just less standardized, in a wrapper library (or libraries).

At 19:59 14/02/05 -0800, Ashley Yakeley wrote:

...

(2) a CalendarTime sans timezone is equivalent to UTC,

No, a CalendarTime without a time zone would simply be a local time. It would not correspond to any particular absolute time.

Yes, something like that... RFC3339 has a trick of using -00:00 offset for this: [[ 4.3. Unknown Local Offset Convention If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC2822 [IMAIL-UPDATE] describes a similar convention for email. ]] -- http://www.ietf.org/rfc/rfc3339.txt I don't recall if this is true in ISO 8601 - maybe not. (I'm not promoting the syntax here, just supporting the general concept.) #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

At 02:38 15/02/05 -0800, Ashley Yakeley wrote:

In article <5.1.0.14.2.20050215100243.02f5de40@127.0.0.1>, Graham Klyne wrote:

...

Yes, something like that... RFC3339 has a trick of using -00:00 offset for this: [[ 4.3. Unknown Local Offset Convention

If the time in UTC is known, but the offset to local time is unknown,

That's not what I meant at all. A CalendarTime without a time zone is a local time, with no information about time zone or time in UTC.

Oops, sorry, you're absolutely right. It's been a while, I mentally misplaced the detail, and failed to notice that when I hooked out the text. In fact, in the case of RFC3339, which is intended to be used for Internet protocol timestamps, the unqualified local time case is not supported, and doesn't really provide any support for this case: [[ 4.4. Unqualified Local Time A number of devices currently connected to the Internet run their internal clocks in local time and are unaware of UTC. While the Internet does have a tradition of accepting reality when creating specifications, this should not be done at the expense of interoperability. Since interpretation of an unqualified local time zone will fail in approximately 23/24 of the globe, the interoperability problems of unqualified local time are deemed unacceptable for the Internet. Systems that are configured with a local time, are unaware of the corresponding UTC offset, and depend on time synchronization with other Internet systems, MUST use a mechanism that ensures correct synchronization with UTC. Some suitable mechanisms are: o Use Network Time Protocol [NTP] to obtain the time in UTC. o Use another host in the same local time zone as a gateway to the Internet. This host MUST correct unqualified local times that are transmitted to other hosts. o Prompt the user for the local time zone and daylight saving rule settings. ]] -- http://www.ietf.org/rfc/rfc3339.txt Sorry for the confusion. Let normal programming resume. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

On 2005-02-15, Keean Schupke wrote:

Linux systems can (and a lot do) have their system type (in the hardware clock) set to GMT. Localtime is calculated from the timezone when you call the gettimeofday function. This in IMHO is much better than windows broken system of actualy moving the clock forwards and back for daylight-savings.

This is standard for all Unices, not Linux specific. If anything, Linux is unusual in that it caters to the other case of keeping the hardware clock in the local timezone, to ease interoperability with Windows (& DOS) on dual-boot systems.

This does mean that the above assumption could be wrong on linux, where the default with no timezone could be GMT.

A system without a default timezone set is exceedingly rare -- all installations force you to set one (which can be overriden on a per-process basis by the environment). -- Aaron Denney -><-