Opened 11 years ago

Closed 11 years ago

#1014 closed defect (fixed)

posix: string->time preserves the year accross multiple invocations

Reported by: certainty Owned by:
Priority: major Milestone: someday
Component: core libraries Version: 4.8.x
Keywords: Cc:
Estimated difficulty:

Description

This bug has been reported by bryanvick.

The following snippet reproduces the problem:

#;1> (string->time "5/18" "%m/%d")
#(0 0 0 18 4 0 5 137 #f 0)

#;2> (string->time "5/18" "%m/%y")
#(0 0 0 18 4 118 5 137 #f 0)

#;3> (string->time "5/18" "%m/%d")
#(0 0 0 18 4 118 5 137 #f 0)

Though the first and the third call should return the same
result, they don't. That's because the second call to string->time
sets the year which is preserved in subsequent calls.

First researches showed that the implementation of C_strptime passes a pointer to the global struct C_tm in the call to strptime(3), which doesn't reset the fields and so a few of them may remain
unchanged. Possible fixes could be:

1) use a fresh struct
2) reset C_tm before it is used

Attachments (1)

0001-Use-sane-default-time-struct-for-string-time-1014.patch (1.7 KB) - added by Jim Ursetto 11 years ago.

Download all attachments as: .zip

Change History (4)

comment:1 Changed 11 years ago by certainty

Milestone: 4.9.0someday

set milestone to someday. I had set that accidently.

comment:2 Changed 11 years ago by Jim Ursetto

This is technically a misuse of strptime, as you shouldn't retrieve fields you haven't set.

One option is to init the struct to the current date, which makes everything relative to today. This is annoying to implement and not always what you want.

Instead I suggest behaving like python: init the struct to 1900/01/01 00:00:00.

The problem is strptime behaves differently on different platforms: for example on OS X, it won't update the weekday or day of year, whereas it does on glibc.

So, the attached patch also uses mktime to ensure week/year day is set. Note that this may, or may not, cause the time to be interpreted as local time. On the other hand, parsing timezones with strptime is hit and miss anyway -- on OS X the only legal timezones are the local TZ and "GMT" (everything else bombs out).

mktime() is a bit of a question mark, I'd want to see testing on a few platforms before applying it. It can be removed, with the caveat that weekday will be wrong as mentioned above.

comment:3 Changed 11 years ago by Jim Ursetto

Resolution: fixed
Status: newclosed

Pushed Peter's patch instead as f08f4d6. It does not use mktime(), just zeroes the struct. Note it also makes a fairly large change to allocate a fresh buffer on every call along with general cleanups. I was not able to test on Windows and there's not really a test suite for UNIX anyway.

Note: See TracTickets for help on using tickets.