On Wed, 8 Jan 2003, Brett Cannon wrote:
> [Kevin Jacobs]
>
> > Hi all,
> >
> > I've just noticed a problem in one of our financial systems that was caused
> > by the new pure-Python strptime module by Brett Cannon.
>
> Lucky me. =)
>
> <snip>
> > Python 2.3-cvs (with #undef HAVE_STRPTIME hard-coded):
>
> Just for future reference, you can just import ``_strptime`` and use
> ``_strptime.strptime()`` instead of having to fiddle with ``time``.
I just removed the #undef HAVE_STRPTIME in the mean time. Thanks for the
tip, though. ;)
> OK, so I will take a look, but if anyone beats me to a solution I will
> have no qualms about it. =)
I suspect that I know the cause, though I have not looked at the source for
the specific code. Basically, your strptime implementation leaves
unspecified information as -1. This is nice, except that it violates the
SVID 3, POSIX, BSD 4.3, ISO 9899 standards. i.e., here is an exerpt from
the mktime man page on my linux system on how the values in a time-tuple are
interpreted:
The mktime() function converts a broken-down time structure, expressed
as local time, to calendar time representation. The function ignores
the specified contents of the structure members tm_wday and tm_yday and
recomputes them from the other information in the broken-down time
structure. If structure members are outside their legal interval, they
will be normalized (so that, e.g., 40 October is changed into 9 Novem-
ber).
Thus, mktime correctly returns a time-from-epoch that is 1 hour, 1 minute,
and 1 second (3661 seconds) behind where it should be (unless it is DST).
Thanks for the quick reply,
-Kevin
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com
Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
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