<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Marcin 'Qrczak' Kowalczyk wrote:
<blockquote cite="mid87ll9qzuig.fsf@qrnik.zagroda" type="cite">
<pre wrap="">Seth Kurtzberg <a class="moz-txt-link-rfc2396E" href="mailto:seth@cql.com"><seth@cql.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Linux (glibc) tries to provide that information. It has lots of rules
even for weird timezones.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
</body>
</html>