>
> 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 th
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 wi
> 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 membe
> -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 Wu
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 (un
> 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 prob
6 matches
Mail list logo
