Mike Gorchak <mike.gorchak....@gmail.com> writes:

>>> So is_date() always return negative result for the text string where
>>> date is placed before time like '2008-02-14 20:30:45'.
>> Yes, it returns this -1 on other platforms, but...
>>> It must fail on
>>> other platforms as well.
> It also fails under Linux, but real problem is not here, it is just an
> unoptimal date parser.

The test does _not_ fail.  That if condition does return -1 on Linux
and BSD, and making tm_to_time_t() return a failure, but the caller
goes on, ending up with the right values in year/month/date in the
tm struct, which is the primary thing the function is used for.

As you said, what is_date() wants to see is if the caller guessed
the order of three combinations of year/month/date correctly, it
cannot necessarily assume the caller already has seen the
hour/minutes/seconds yet, so _temporarily_ feeding a valud set of
values to hour/minutes/seconds when calling tm_to_time_t() is a good
workaround.  So the change in your patch sounds correct and use of a
temporary tm to avoid contaminating the hour/minutes/seconds passed
to the is_date() function while doing so looks good.

>> ... the input '2008-02-14 20:30:45' still parses fine for others
>> (including me).  That is what is puzzling.
>> A shot in the dark: perhaps your time_t is unsigned?
> Yeah, it was a headshot :) It really due to unsigned time_t. I will
> send two patches right now with fixes regarding unsigned time_t
> comparison.

If your time_t is unsigned, the error returned from tm_to_time_t()
will appear to be a time in a distant future, which will prevent
is_date() to return "Yeah, you guessed the order of year, month, and
date correctly" to its caller.  The code would need to pick a safer
mechanism to signal a failure from tm_to_time_t() to its callers.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to