From nobody@FreeBSD.org  Wed Dec  6 03:38:21 2000
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 209AD37B400
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  6 Dec 2000 03:38:20 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id eB6BcKI16987;
	Wed, 6 Dec 2000 03:38:20 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200012061138.eB6BcKI16987@freefall.freebsd.org>
Date: Wed, 6 Dec 2000 03:38:20 -0800 (PST)
From: simon@comsys.ntu-kpi.kiev.ua
Sender: nobody@FreeBSD.org
To: freebsd-gnats-submit@FreeBSD.org
Subject: TZ implementation: changes in TZ don't make effect on running process
X-Send-Pr-Version: www-1.0

>Number:         23323
>Category:       misc
>Synopsis:       TZ implementation: changes in TZ don't make effect on running process
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          wish
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec 06 03:40:01 PST 2000
>Closed-Date:    Mon Dec 18 13:07:02 PST 2000
>Last-Modified:  Mon Dec 18 13:09:46 PST 2000
>Originator:     Andrey Simonenko
>Release:        4.1-STABLE i386
>Organization:
>Environment:
>Description:
I found out that implementation of time zone (local time, date, etc.)
has one problem. May be I missed something but I think that following
will be interesting.

If some process calls one of functions which operates with local time,
then all other calls of such functions will use time zone got in first
call.

Example. There is some program with following code:

time_t    curr_time;
struct tm curr_tm;
...
for (;;) {
    curr_time = time((time_t *)0);
    localtime_r(&curr_time, &curr_tm);
    ....    /* do something which takes some minutes */
}

Let current time zone is EST. Program calls localtime_r() and gets local
time adjusted to this time zone. Some time latter time zone is changed
(for example by tzsetup program). New time zone makes new adjustment for
local time. But it will take effect only for programs run after time
zone changes.
Our example program will still use local time adjustment for time zone
EST.

This isn't problem for most of programs, but for programs which
sensitive for local time it makes some kind of problems.

I looked at implementation of localtime_r() (and some other functions
like this one) and found out that they call functions tzset() and
tzsetwall(). But tzsetwall() remembers that it has been called and
doesn't allow to ``call'' itself two times (lcl_is_set variable). May be
it is possible to play with environment variable TZ, but I didn't find
good solution.

If I didn't find function which allows to ``restart'' tzset() and
tzsetwall() please tell me. If I'm right then I think that functions
tzreset() and tzresetwall() will be useful. Implementations of these
functions are quite simple: they should set some variables to initial
values and call tzset() and tzsetwall() respectively.

What do you think about all this?
>How-To-Repeat:
I think that functions tzreset() and tzresetwall() will be useful. Implementations of these functions are quite simple: they should set some variables to initial values and call tzset() and tzsetwall() respectively.
>Fix:


>Release-Note:
>Audit-Trail:

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: simon@comsys.ntu-kpi.kiev.ua
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: misc/23323: TZ implementation: changes in TZ don't make effect on running process
Date: Sun, 10 Dec 2000 13:54:52 -0500 (EST)

 <<On Wed, 6 Dec 2000 03:38:20 -0800 (PST), simon@comsys.ntu-kpi.kiev.ua said:
 
 > If some process calls one of functions which operates with local time,
 > then all other calls of such functions will use time zone got in first
 > call.
 
 This is by design, and probably won't be fixed until the C standard is
 amended or updated to specify a thread-safe interface to the timezone
 library routines.  It's impossible to predict what the people working
 on this issue will come up with (if they ever do).
 
 -GAWollman
 
 
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Mon Dec 18 13:07:02 PST 2000 
State-Changed-Why:  
Environment variables like TZ cannot be changed for a running 
process unless it does it on its own, so tzsetup will by definition 
not have any effect on processes which derive their timezone from 
the environment. 

Processes which derive their timezone from the system wide default 
in /etc/localtime could do a stat(2) on that file to discover if 
the timezone changed. 

The case for a general need to spend performance on this scenario 
is not proven. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=23323 
>Unformatted:
