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

Re: Weird time-zone oscillation



On 12/13/2009 09:53 PM, Kumar Appaiah wrote:
On Sun, Dec 13, 2009 at 02:47:38PM -0600, Kumar Appaiah wrote:
OK, there's a bug in your program:

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

int main(void) {
	char *iso_date = "2009-12-11T2:50:00";
	struct tm tm; /*<- NOT INITIALIZED! */
	time_t time;

	strptime(iso_date, "%FT%T",&tm);
	time = mktime(&tm);
	printf("%ld\t%d\n", time, tm.tm_isdst);
	return 0;
}

If I 	memset(&tm, 0, sizeof(struct tm));, the bug goes away.

Here's the deal: The same bug exists glib. No wonder! The maintainer
of alarm-clock helped me figure that out, and will reassign the bug to
glib (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558099 )

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?

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.

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

--
David Kubicek


Reply to: