Debian Bug report logs - #24002
libc6: Timezone handling has changed AGAIN

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>

To: submit@bugs.debian.org

Subject: libc6: Timezone handling has changed AGAIN

Date: Sat, 27 Jun 1998 16:28:44 -0600

Package: libc6
Version: 2.0.7r-2

This is getting old, the handling of the 'timezone' variable keeps changing, 
a few releases ago it was -ve, now it's +ve and now it's +ve + 1 hour, for
example:

#include <time.h>
#include <stdio.h>

int main()
{
   // Load the timezone variable
   time_t Time = 0;
   localtime(&Time);
   
   printf("Timezone is -%u\n",timezone/60/60);
   return 0;
}          

Wakko{jgg}/tmp#./a.out
Timezone is -7
Wakko{jgg}/tmp#822-date
Sat, 27 Jun 1998 16:16:08 -0600  

What's up with that? Last release this returned -6. One possibility is that
glibc has started encoding daylight savings in some fashion, but then the
comments in time.h are wrong.

The functions inside glibc to handle time account for the timezone
correctly, but the only way to generate a time_t structure from broken-down
struct tm is with the undocumented, GNU specific timegm function - since
timezone doesn't work consistantly!

-- System Information
Debian Release: 2.0
Kernel Version: Linux Wakko 2.0.34 #4 Sat Jun 6 20:28:53 MDT 1998 i486 unknown

Versions of the packages libc6 depends on:
ii  ldso            1.9.9-1        The Linux dynamic linker, library and utilit

Message #10 received at 24002@bugs.debian.org (full text, mbox, reply):

From: Dale Scheetz <dwarf@polaris.net>

To: Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>, 24002@bugs.debian.org

Subject: Re: Bug#24002: libc6: Timezone handling has changed AGAIN

Date: Sat, 27 Jun 1998 22:31:44 -0400 (EDT)

On Sat, 27 Jun 1998, Jason Gunthorpe wrote:

> Package: libc6
> Version: 2.0.7r-2
> 
> This is getting old, the handling of the 'timezone' variable keeps changing, 
> a few releases ago it was -ve, now it's +ve and now it's +ve + 1 hour, for
> example:
>
I have heard so much about timezones that, while this is the first I have
heard of this, I am not too surprised. The last several releases were
pre-releases where lots of stuff was changing. I take it from your
comments that this is still not fixed.

I know I'm the maintainer of this package, but if you would treat me like
I was a total idiot, you will get closer to the truth ;-)

I can follow the example blow, but the context is too sketchy for me to
tell what the output should be, even though you told me. I guess I am
asking for some more details on the who what and where...

 
> #include <time.h>
> #include <stdio.h>
> 
> int main()
> {
>    // Load the timezone variable
>    time_t Time = 0;
>    localtime(&Time);
>    
>    printf("Timezone is -%u\n",timezone/60/60);
>    return 0;
> }          
> 
> Wakko{jgg}/tmp#./a.out
> Timezone is -7
> Wakko{jgg}/tmp#822-date
> Sat, 27 Jun 1998 16:16:08 -0600  
> 
> What's up with that? Last release this returned -6. One possibility is that
> glibc has started encoding daylight savings in some fashion, but then the
> comments in time.h are wrong.
> 
> The functions inside glibc to handle time account for the timezone
> correctly, but the only way to generate a time_t structure from broken-down
> struct tm is with the undocumented, GNU specific timegm function - since
> timezone doesn't work consistantly!
> 
You mean between one release and another, or within one release? This
sound like a coordination problem between several routines that are all
required to be "on the same page" for timezones to work?

It is possible that the timezone is now supposed to reflect the current
offset from GMT, including DST as part of that offset, but I would expect
the date output to agree.

I'm certainly not going to try to untangle what the code "should do", and
at this point I need a bit more amunition to go to the upstream maintainer
with this issue.

Thoughts?

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-

Message #15 received at 24002@bugs.debian.org (full text, mbox, reply):

From: Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>

To: Dale Scheetz <dwarf@polaris.net>

Cc: 24002@bugs.debian.org

Subject: Re: Bug#24002: libc6: Timezone handling has changed AGAIN

Date: Sat, 27 Jun 1998 20:51:46 -0600 (MDT)

On Sat, 27 Jun 1998, Dale Scheetz wrote:

 
> I can follow the example blow, but the context is too sketchy for me to
> tell what the output should be, even though you told me. I guess I am
> asking for some more details on the who what and where...

The problem here is straightforward, the 'timezone' variable keeps
changing it's meaning between releases. In this release I think it is
correct - but the man page is very unclear about how to use it
(mktime(3) )

> > #include <time.h>
> > #include <stdio.h>
> > 
> > int main()
> > {
> >    // Load the timezone variable
> >    time_t Time = 0;
> >    localtime(&Time);
> >    
> >    printf("Timezone is -%u\n",timezone/60/60);
> >    return 0;
> > }          
> > 
> > Wakko{jgg}/tmp#./a.out
> > Timezone is -7
> > Wakko{jgg}/tmp#822-date
> > Sat, 27 Jun 1998 16:16:08 -0600  

> You mean between one release and another, or within one release? This
> sound like a coordination problem between several routines that are all
> required to be "on the same page" for timezones to work?

I have not found any inconsitancies within the routines that use this
variable, only in that public variable.
 
> It is possible that the timezone is now supposed to reflect the current
> offset from GMT, including DST as part of that offset, but I would expect
> the date output to agree.

AFIAK timezone should be the number of seconds offset from GMT including
excluding seasonal shift - previous releases included the seasonal shift
[or something like that]. In truth that's not really sufficient to deal
with date translations but some BSD programs may depend on this.

This might not be a serious issue, I probably shouldn't use timezone for
time computations (timegm - though unportable - is a better choice) but I
think at a minimum the man page should be clarified and a timegm should be
mentioned on the mktime page. Unfortunately there is no portable way to
put arbitary time into a time_t structure :<

Jason

Send a report that this bug log contains spam.