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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org