|
Home > Archive > Unix Programming > April 2005 > Timezone change questions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Timezone change questions
|
|
|
| On Linux, do gmtime and localtime with the TZ set correctly take into
account changes in daylight savings time definitions over the years?
And, does the TZ set change the current TZ for all threads or just the
current thread? If so, is there a way to pass a timezone to the gmtime
and localtime functions to get a correct and threadsafe time zone?
Thanks!
| |
| joe@invalid.address 2005-04-07, 6:11 pm |
| "stork" <tbandrow@mightyware.com> writes:
> On Linux, do gmtime and localtime with the TZ set correctly take
> into account changes in daylight savings time definitions over the
> years?
gmtime() doesn't have DST corrections, it's just GMT/UTC.
The man page for localtime() describes essentially the same behavior
as POSIX, ie, DST is taken into account. I'm not sure what you mean by
"changes in daylight savings time definitions over the years". If you
mean, given a timestamp from some time in the past, will DST be
handled correctly for that point in time, it depends on whether the
zoneinfo database is correct for that point in time.
> And, does the TZ set change the current TZ for all threads or just
> the current thread? If so, is there a way to pass a timezone to the
> gmtime and localtime functions to get a correct and threadsafe time
> zone?
TZ is a process wide environmental variable, so it affects all
threads.
Joe
| |
|
| TJB replied to:
> TZ is a process wide environmental variable, so it affects all
> threads.
>
So, if I have a multithreaded server side app that needs me to have a
time api that handles conversions to various local times and back,
would it be an appropriate strategy to go dig in the source for
localtime and mktime, and then, hack up an interface that takes
whatever state stuff gets set by TZ and so that I can make it
threadsafe?
So, I would have, something like this:
time_zone_information *tz;
tz = findtz( "US Eastern Prevailing Time" );
stuff = localtime( tz, mytime_t );
Has someone already done this?
Thanks!
| |
| Dragan Cvetkovic 2005-04-07, 6:11 pm |
| "stork" <tbandrow@mightyware.com> writes:
> TJB replied to:
>
>
> So, if I have a multithreaded server side app that needs me to have a
> time api that handles conversions to various local times and back,
> would it be an appropriate strategy to go dig in the source for
> localtime and mktime, and then, hack up an interface that takes
> whatever state stuff gets set by TZ and so that I can make it
> threadsafe?
>
> So, I would have, something like this:
>
> time_zone_information *tz;
>
> tz = findtz( "US Eastern Prevailing Time" );
>
> stuff = localtime( tz, mytime_t );
Can you use gettimeofday() function? Its argument is also a timezone and it
is MT-safe?
Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!!
| |
| joe@invalid.address 2005-04-07, 6:11 pm |
| "stork" <tbandrow@mightyware.com> writes:
> So, if I have a multithreaded server side app that needs me to have
> a time api that handles conversions to various local times and back,
> would it be an appropriate strategy to go dig in the source for
> localtime and mktime, and then, hack up an interface that takes
> whatever state stuff gets set by TZ and so that I can make it
> threadsafe?
>
> So, I would have, something like this:
>
> time_zone_information *tz;
>
> tz = findtz( "US Eastern Prevailing Time" );
>
> stuff = localtime( tz, mytime_t );
I suppose you could, but it would be non-trivial. Maybe it would be
easier to dedicate a thread to doing conversions, and let the other
threads put requests in a job queue for it?
> Has someone already done this?
Not that I know of.
Joe
| |
| joe@invalid.address 2005-04-07, 6:11 pm |
| Dragan Cvetkovic <me@privacy.net> writes:
> "stork" <tbandrow@mightyware.com> writes:
>
> Can you use gettimeofday() function? Its argument is also a timezone
> and it is MT-safe?
You mean the second parameter? The only system I know of that makes
use of it is FreeBSd. Linux ignores it, and SUS says that if it's
non-null the behavior is unspecified.
Even if it were to be used, I'm not clear on what it would be used
for. There isn't enough information in it to tell when DST would be in
effect, or what the adjustment would be for DST.
Joe
| |
| Villy Kruse 2005-04-08, 2:52 am |
| On 7 Apr 2005 08:43:16 -0700,
stork <tbandrow@mightyware.com> wrote:
> On Linux, do gmtime and localtime with the TZ set correctly take into
> account changes in daylight savings time definitions over the years?
>
Linux uses the D.A.Olson's tz database and this database goes to
great length to interpret historical timezone changes back as far
as data is available.
Villy
| |
| Kenny McCormack 2005-04-12, 6:02 pm |
| In article <slrnd5ccqv.it0.vek@station02.ohout.pharmapartners.nl>,
Villy Kruse <nobody> wrote:
>On 7 Apr 2005 08:43:16 -0700,
> stork <tbandrow@mightyware.com> wrote:
>
>
>
>Linux uses the D.A.Olson's tz database and this database goes to
>great length to interpret historical timezone changes back as far
>as data is available.
That is good. But I interpreted this thread to be asking about the future,
not the past.
I.e., I have a Linux system - it switched to DST on April 3rd, 2005.
Suppose our loony government goes ahead with its current plans to change
DST to start in early March (and end around Thanksgiving).
Will my system do the right thing next year?
I would assume the answer is No, unless the OS time routines are
"Internet-connected" - i.e., they go out to some central server to get the
latest government mickey-mouse.
| |
| joe@invalid.address 2005-04-12, 6:02 pm |
| gazelle@yin.interaccess.com (Kenny McCormack) writes:
> In article <slrnd5ccqv.it0.vek@station02.ohout.pharmapartners.nl>,
> Villy Kruse <nobody> wrote:
>
> That is good. But I interpreted this thread to be asking about the
> future, not the past.
>
> I.e., I have a Linux system - it switched to DST on April 3rd, 2005.
> Suppose our loony government goes ahead with its current plans to
> change DST to start in early March (and end around Thanksgiving).
>
> Will my system do the right thing next year?
If the timezone database is updated before it happens it should do the
right thing. For events that are known to be coming the Olson database
should get updated and you can download and install the updates from
ftp://elsie.nci.nih.gov/pub/
Alternatively you can setup TZ to be a POSIX timezone string which
gives a complete spec for whatever our loony government comes up
with.
Joe
| |
| Kenny McCormack 2005-04-12, 6:02 pm |
| In article <m3sm1wf5hb.fsf@invalid.address>, <joe@invalid.address> wrote:
>gazelle@yin.interaccess.com (Kenny McCormack) writes:
....
>
>If the timezone database is updated before it happens it should do the
>right thing. For events that are known to be coming the Olson database
>should get updated and you can download and install the updates from
>ftp://elsie.nci.nih.gov/pub/
Ah, but then I assume from the sense of your posting that the answer to my
question is "No. It doesn't 'just work'." You have to do something
manually to keep things up-to-date.
I understand that, in the context of how newsgroup readers/posters think,
this last comment of mine sounds like whining ("It's so haaaaaaaaard"), but
that's not the point. The point is that it would, in a perfect world, be
automatic. Obvious flamebait: I would imagine that, in the Microsoft
world, it is (automatic).
>Alternatively you can setup TZ to be a POSIX timezone string which
>gives a complete spec for whatever our loony government comes up
>with.
(Not to mention all the other loony governments around the globe)
More manual work. Not that this has anything to do with how *my* systems
are run; this is just a theoretical discussion.
| |
|
|
TJB replied to:
> I understand that, in the context of how newsgroup readers/posters
think,
> this last comment of mine sounds like whining ("It's so
haaaaaaaaard"), but
> that's not the point. The point is that it would, in a perfect
world, be
> automatic. Obvious flamebait: I would imagine that, in the
Microsoft
> world, it is (automatic).
>
Actually in the MS world it is much, much worse. For all intents and
purposes conversion from a UTC to a random local time is considered not
implemented by MS. And it certainly does not exist in .NET 1.0 or 1.1.
In Whidbey, .NET 2.0, the developers wrote a giant blog entry
explaining why they yet again screwed up time representation.
Basically, they said, they did not want to break existing code, so, we
are stuck with their bad ideas! They also mentioned that the defacto
TZ database on Windows, the registry, is considered so bad by even MS
that they do not expose any real APIs for it. It really sucks
actually.
Certainly, under Windows, a C/C++ program that converts from a UTC to a
time prior to 1986 will not show the correct representation for the
USA, but, Solaris will and if I understand this thread correctly, so
will Linux.
The upshot is that under Windows, if they do pass the change in DST,
then, most users will be screwed even more than they are now. But,
under Linux it really won't matter so long as the tz database gets
updated.
| |
| joe@invalid.address 2005-04-12, 6:02 pm |
| gazelle@yin.interaccess.com (Kenny McCormack) writes:
> In article <m3sm1wf5hb.fsf@invalid.address>, <joe@invalid.address> wrote:
> ...
>
> Ah, but then I assume from the sense of your posting that the answer
> to my question is "No. It doesn't 'just work'." You have to do
> something manually to keep things up-to-date.
>
> I understand that, in the context of how newsgroup readers/posters
> think, this last comment of mine sounds like whining ("It's so
> haaaaaaaaard"), but that's not the point. The point is that it
> would, in a perfect world, be automatic.
Sure, but since there's no such thing as a perfect world, what's the
point of comparing reality to it?
No matter what system you have, it must have some way of tracking the
purely political changes to DST. There is no algorithm that could be
used to figure out what politicians have done or will do.
Joe
| |
| Ralf Fassel 2005-04-12, 6:02 pm |
| * gazelle@yin.interaccess.com (Kenny McCormack)
| I understand that, in the context of how newsgroup readers/posters
| think, this last comment of mine sounds like whining ("It's so
| haaaaaaaaard"), but that's not the point. The point is that it
| would, in a perfect world, be automatic. Obvious flamebait: I would
| imagine that, in the Microsoft world, it is (automatic).
Even on Windows you have to have at least automatic updates
configured, otherwise the system also will not automatically adjust to
changes of timezone politics. And if you configure your Linux system
to update in the same way as the Windows system, I would expect an
automatic adjustment on Linux, too (the distros include the latest
timezone info, don't they?)
R'
| |
| Kenny McCormack 2005-04-13, 2:52 am |
| In article <m3oeckf10x.fsf@invalid.address>, <joe@invalid.address> wrote:
>gazelle@yin.interaccess.com (Kenny McCormack) writes:
>
>Sure, but since there's no such thing as a perfect world, what's the
>point of comparing reality to it?
I think you know the answer to this.
>No matter what system you have, it must have some way of tracking the
>purely political changes to DST. There is no algorithm that could be
>used to figure out what politicians have done or will do.
Yes, there is. It is called, in one form or another, "automatic updates".
That is, the OS periodically goes out over the wire to a central location
on the Internet and gets the latest stuff (w/o manual intervention).
Quite honestly, the reaosn I have interacted with this thread at all was to
try to determine if that had been implemented - and I believe I have my
answer - and for that, I thank you.
| |
| Gordon Burditt 2005-04-13, 2:52 am |
| >>No matter what system you have, it must have some way of tracking the
>
>Yes, there is. It is called, in one form or another, "automatic updates".
That just means that SOMEBODY ELSE does the updates. The politicians
aren't even so nice as to directly notify the person maintaining
the files. I don't know where the maintainer watches for such
changes.
>That is, the OS periodically goes out over the wire to a central location
>on the Internet and gets the latest stuff (w/o manual intervention).
And who updates the central location?
Gordon L. Burditt
| |
| Villy Kruse 2005-04-13, 2:52 am |
| On Tue, 12 Apr 2005 18:35:06 +0200,
Ralf Fassel <ralfixx@gmx.de> wrote:
> * gazelle@yin.interaccess.com (Kenny McCormack)
>| I understand that, in the context of how newsgroup readers/posters
>| think, this last comment of mine sounds like whining ("It's so
>| haaaaaaaaard"), but that's not the point. The point is that it
>| would, in a perfect world, be automatic. Obvious flamebait: I would
>| imagine that, in the Microsoft world, it is (automatic).
>
> Even on Windows you have to have at least automatic updates
> configured, otherwise the system also will not automatically adjust to
> changes of timezone politics. And if you configure your Linux system
> to update in the same way as the Windows system, I would expect an
> automatic adjustment on Linux, too (the distros include the latest
> timezone info, don't they?)
>
That realy would require that the database is updated separately from
any other components. RedHat, for example, includes the timezone data
files as an integral part of glibc package and only an upgrade of glibc
will update the time zone data base.
Villy
| |
| Keith Thompson 2005-04-13, 2:52 am |
| joe@invalid.address writes:
[...]
> No matter what system you have, it must have some way of tracking the
> purely political changes to DST. There is no algorithm that could be
> used to figure out what politicians have done or will do.
Of course it's not possible to predict what they're going to do, but
there should be some consistent way to distribute the information. I
wonder if timezone and DST information could be added to (a future
version of) the NTP protocol.
On the other hand, defining and implementing such a thing would be
more work than a one-time update to the timezone databases. It would
be worthwhile only if we expected the rules to change multiple times
in the future.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
| |
| joe@invalid.address 2005-04-13, 5:59 pm |
| gazelle@yin.interaccess.com (Kenny McCormack) writes:
> In article <m3oeckf10x.fsf@invalid.address>, <joe@invalid.address>
> wrote:
>
> I think you know the answer to this.
Thanks for your confidence in me :-)
>
> Yes, there is. It is called, in one form or another, "automatic
> updates".
>
> That is, the OS periodically goes out over the wire to a central
> location on the Internet and gets the latest stuff (w/o manual
> intervention).
But that's not an algorithm, it's a manual process that someone else
does. It's not even automatic because you won't know when changes will
be made, so if your machine goes looking "periodically" you stand a
good chance of being out of date for the rest of the period after a
change is added to the repository.
Not to mention the delay between when the politicians decide to change
something and when the maintainer of the database finds out about it
and actually makes the change.
> Quite honestly, the reaosn I have interacted with this thread at all
> was to try to determine if that had been implemented - and I believe
> I have my answer - and for that, I thank you.
You're welcome.
Joe
| |
|
| Actually I was more asking was:
If I have a loop going UTC seconds from 1970 to present, would I get
the correct local time as understood at that given UTC time when I
convert from UTC to local?
That is, would a conversion from UTC to local in the United States in
1984 have pre- 1986 DST rules for that conversion?
| |
| Casper H.S. Dik 2005-04-20, 5:52 pm |
| "stork" <tbandrow@mightyware.com> writes:
>Actually I was more asking was:
>If I have a loop going UTC seconds from 1970 to present, would I get
>the correct local time as understood at that given UTC time when I
>convert from UTC to local?
>That is, would a conversion from UTC to local in the United States in
>1984 have pre- 1986 DST rules for that conversion?
Yes. See /usr/share/lib/zoneinfo
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
|
|
|
|
|