Mail Archives: cygwin/2006/04/25/15:27:36
Corinna Vinschen wrote:
> On Apr 25 16:17, Christian Franke wrote:
>
>> Corinna Vinschen wrote:
>>
>>> Can you tell me exactly where the problem
>>> happens which leads to this patch, please?
>>>
>> partime.c:
>> ...
>> parse_pattern_letter (s, c, t)
>> ...
>> case 's': /* second [00-60 followed by optional fraction] */
>> {
>> int frac;
>> s = parse_decimal (s, 2, 0, 60, 1, &t->tm.tm_sec, &frac);
>> t->tm.tm_sec += frac;
>> }
>>
>> parse_decimal("59.50001", ...) returns tm_sec = 59 and frac=1 which
>> results in tm_sec=60, but maketime({...; tm.tm_sec=60;...}, .) returns
>> -1 always.
>>
>
> Yeah, these are exactly the lines which you patch. When I asked for
> where exactly the problem happens, I was asking where maketime makes the
> mistake of not taking denormalized timestamps into account, where the
> condition is which let it return -1.
>
IMO maketime() does not make any mistake.
> Don't get me wrong, I appreciate the patch, but since you provided a
> patch, I assumed you already debugged this problem, so you can point to
> the place where it happens.
According to the algorithm used and the comment in line 295:
"ISO 8601 day-of-year and week numbers are not yet supported."
maketime() is (unlike mktime()) simply not designed to accept
denormalized timestamps.
This is OK for the purpose maketime() used inside of patch, except for
this one rare case described.
> Yes, I'm a lazy chicken and I'm just trying
> to avoid double work ;-)
>
I took the (lazy) approach to fullfill maketime's interface contract and
allow a < 0.5s round error ;-)
Christian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -