Re: strptime error when setting a different TimeZone with export TZ=UTC

2005-06-24 Thread Eric Blake
I would like to be able to parse the date in UTC, but it seams that either the strptime or the mktime function do not like the modification of the TZ environment variable. I also tried to printout the broken-down date structure try and it seams to be correct, so I suppose that the problem

Re: strptime error when setting a different TimeZone with export TZ=UTC

2005-06-24 Thread Brian Dessent
Luca Wullschleger wrote: Hi everybody. I have a very specific problem and I'm looking for someone giving me a solution. I'm afriad this is operator error on your part. struct tm try; Here 'try' starts out as a regular automatic variable, with all of its fields set to arbitrary

RE: strptime error when setting a different TimeZone with export TZ=UTC

2005-06-24 Thread Luca Wullschleger
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dessent Sent: vendredi, 24. juin 2005 21:37 To: cygwin@cygwin.com Subject: Re: strptime error when setting a different TimeZone with export TZ=UTC Luca Wullschleger wrote: Hi everybody. I

Re: strptime error when setting a different TimeZone with export TZ=UTC

2005-06-24 Thread Eric Blake
Here you call strptime() to fill in the values of 'try', however the strptime function has the semantics that it will only fill in the members of struct tm that it is asked to parse. This means that after the call, some of the members still have undefined values. Specifically, the members

Re: strptime error when setting a different TimeZone with export TZ=UTC

2005-06-24 Thread Brian Dessent
Eric Blake wrote: Not necessarily. According to POSIX, a strptime implementation is allowed (but not necessarily recommended) to set all fields of try, even the ones not related to what was parsed: It is unspecified whether multiple calls to strptime() using the same tm structure will

Re: strptime error when setting a different TimeZone with export TZ=UTC

2005-06-24 Thread Eric Blake
Actually tm_mon must be in the range [0,11]. You might have been thinking of tm_mday which unlike all the others is 1-based, [1,31]. You got me, and I even had the POSIX spec open in front of me when I read the wrong line as to which field was 1-based. :) In this particular example