[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Weird time-zone oscillation



On Sun, Dec 13, 2009 at 10:57:24PM +0100, David Kubicek wrote:
>>> Thanks, all, for helping me. Sorry for wasting your time.
>>
>> FYI: http://git.gnome.org/cgit/glib/commit/?id=2321e5aed07154761223bb124770beba56700e41
>>
>
> New development, I see. :)
>
> You know, struct tm doesn't need to be zeroed before strptime(), that's  
> *NOT* a bug. If you don't get NULL, the date is parsed. The screwball  
> seems to be that your version of libc doesn't touch tm_isdst member at  
> all (should be -1). But if that's how your libc behaves, setting  
> tm_isdst = 0 (via memset()) is a *BUG* too, of course. Still, no shame  
> in making the same mistake as Glib people. :)
>
> I looked it up and SUSv3 says strptime() doesn't touch tm_isdst, so it  
> really should be set to -1 *after* each call.
>
> This is the first time I've seen this, though, and I use strptime()  
> often in my SW, mostly for timestamps which would be discovered by  
> people rather quickly! :) Are you sure you're not using an alternative  
> impl. of libc?

Well, in Debian, we use eglibc:

http://packages.qa.debian.org/e/eglibc.html
http://www.eglibc.org/home

> Anyway, I've run this binary on 15 servers now and all worked fine  
> (RHEL4/5, SuSE, Debian). Each and every libc version I've tested it on  
> sets tm_isdst to -1. That means "DST not yet detected", if mktime() is  
> called later, it will know it has to detect DST itself. If your libc  
> *doesn't* do this for you, setting it to *0* pre-call is even worse. It  
> means "no DST" and mktime will not verify it. Only -1 is acceptable as  
> input to mktime, unless of course you check DST yourself and set 0/1 as  
> an informed action.

Well, let me add to your statement that we've been able to reproduce
this error ONLY on amd64 machines. I am also surprised at why this is
the case, and I'll dig into your advice above subsequently. However,
note this, from my mktime man page:

       The mktime() function modifies the fields of the tm structure
       as follows: tm_wday and tm_yday are set to values determined
       from the contents of the other fields; if structure members are
       outside their valid interval, they will be normalized (so that,
       for example, 40 October is changed into 9 November); tm_isdst
       is set (regardless of its initial value) to a positive value or
       to 0, respectively, to indicate whether DST is or is not in
       effect at the specified time.  Calling mktime() also sets the
       exter‐ nal variable tzname with information about the current
       timezone.

Anyway, I'll dig deeper at a later time.

> I'm glad we got to the solution and this -1 behaviour of other systems  
> is definitely good to know! Thanks too.

Me too. Now I can sleep more peacefully! :-)

Thanks again!

Kumar
-- 
The chat program is in public domain.  This is not the GNU public license.
If it breaks then you get to keep both pieces.
		-- Copyright notice for the chat program

Attachment: signature.asc
Description: Digital signature


Reply to: