Summary
posix: string->time preserves the year accross multiple invocations
Metadata
- Id: d8b29b01a7e3e9880cd04617bed360d9a545abe1
- Trac id: 1014
- Type: defect
- Reporter: certainty
- Owner:
- Cc:
- Status: closed
- Component: core libraries
- Estimated difficulty:
- Resolution: fixed
- Priority: major
- Milestone: someday
- Version: 4.8.x
- Changetime: 2013-07-10 03:23:53 UTC
- Created: 2013-05-24 21:08:16 UTC
- Keywords:
Attachments
- d8b29b01a7e3e9880cd04617bed360d9a545abe1/attachments/0001-Use-sane-default-time-struct-for-string-time-1014.patch
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
Changes and comments
[2013-05-24 21:23:53 UTC] certainty changed milestone from 4.9.0 to someday
[2013-05-24 21:23:53 UTC] certainty wrote:
set milestone to someday. I had set that accidently.
[2013-05-25 03:11:14 UTC] zbigniew wrote:
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.
[2013-05-25 03:16:44 UTC] zbigniew attached 0001-Use-sane-default-time-struct-for-string-time-1014.patch (description=#f)
[2013-07-10 03:23:53 UTC] zbigniew changed status from new to closed
[2013-07-10 03:23:53 UTC] zbigniew set resolution to fixed
[2013-07-10 03:23:53 UTC] zbigniew wrote:
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.