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!

[ Post a follow-up to this message ]

"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

[ Post a follow-up to this message ]

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!

[ Post a follow-up to this message ]

"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 !!!

[ Post a follow-up to this message ]

"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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]