[Brett Cannon]
> ...
> And if anyone out there has some strptime docs that they feel I
> should take a look at (sans OpenBSD's man page since that is what
> this implementation is based on), let me know.
I believe strptime is a x-platform mess. The POSIX docs aren't clear, but
seem to imply that the struct tm* passed to strptime() is both input and
output, and that strptime() is supposed to leave all the fields alone except
for those explicitly given new values by the format string, and even then
doesn't define exactly which fields those are beyond saying "the appropriate
tm structure members":
http://www.opengroup.org/onlinepubs/007908799/xsh/strptime.html
It doesn't say anything about how out-of-range values are to be treated.
See the Python nondist/sandbox/datetime/datetime.py's class tmxxx for one
plausible way to normalize out-of-range fields, if that's necessary. How
that's supposed to work in all cases is also clear as mud, and POSIX is
useless:
http://www.opengroup.org/onlinepubs/007908799/xsh/mktime.html
It echoes the C std so far as it goes, but omits the C standard's crucial
additional text:
If the call is successful, a second call to the mktime function with
the resulting struct tm value shall always leave it unchanged and
return the same value as the first call. Furthermore, if the
normalized time is exactly representable as a time_t value, then
the normalized broken-down time and the broken-down time generated
by converting the result of the mktime function by a call to
localtime shall be identical.
This doesn't specify an algorithm for normalization, but constrains possible
algorithms via cross-function invariants that must be maintained.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4