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

[certainty]

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

[certainty]

set milestone to someday. I had set that accidently.

[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.

[Jim Ursetto]

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.