time

[Bryan]

can someone explain to me why i get different values for the tm_yday and
tm_isdst values?

import rfc822
rfc822.parsedat e('Mar 1 01:03:59 2004') (2004, 3, 1, 1, 3, 59, 0, 0, 0)
import time
time.strptime(' Mar 1 01:03:59 2004', '%b %d %H:%M:%S %Y')

(2004, 3, 1, 1, 3, 59, 0, 61, -1)
thanks,

bryan

[Steve Holden]

Bryan wrote:

can someone explain to me why i get different values for the tm_yday and
tm_isdst values?

>>> import rfc822
>>> rfc822.parsedat e('Mar 1 01:03:59 2004') (2004, 3, 1, 1, 3, 59, 0, 0, 0)
>>> import time
>>> time.strptime(' Mar 1 01:03:59 2004', '%b %d %H:%M:%S %Y')

(2004, 3, 1, 1, 3, 59, 0, 61, -1)

The trivial answer is "because of differences in the modules". Your
question is a bit like asking "Why is the sky today not the same color
as it was yesterday?"

The docs for the time module explain that for strptime(): """The default
values used to fill in any missing data is [sic] (1900, 1, 1, 0, 0, 0,
0, 1, -1)""" and """Support for the %Z directive is based on the values
contained in tzname and whether daylight is true. Because of this, it is
platform-specific except for recognizing UTC and GMT which are always
known (and are considered to be non-daylight savings timezones). """

Note that strptime used only to be present if your platform's C library
provided it; though I can't say for sure that's changed I believe it
has. No idea when, though.

The rfc822 docs for parsedate, on the other hand, specifically remark
"""Note that fields 6, 7, and 8 of the result tuple are not usable.""".

So I suspect you are simply being disturbed by the lack of a consistency
that was never intended to exist: you reads the docs and makes yer
choice - ultimately, do what works in your application.

carefully-not-mentioning-hobgoblins-ly y'rs - steve

[Gerrit]

Steve Holden wrote:

Bryan wrote:

can someone explain to me why i get different values for the tm_yday and
tm_isdst values?

>> import rfc822
>> rfc822.parsedat e('Mar 1 01:03:59 2004')

(2004, 3, 1, 1, 3, 59, 0, 0, 0)

>> import time
>> time.strptime(' Mar 1 01:03:59 2004', '%b %d %H:%M:%S %Y')

(2004, 3, 1, 1, 3, 59, 0, 61, -1)

The trivial answer is "because of differences in the modules". Your
question is a bit like asking "Why is the sky today not the same color
as it was yesterday?"

See also:

http://www.python.org/sf/748843

Gerrit.

--
Weather in Twenthe, Netherlands 28/09 08:55:
15.0°C mist overcast wind 4.0 m/s SW (57 m above NAP)
--
In the councils of government, we must guard against the acquisition of
unwarranted influence, whether sought or unsought, by the
military-industrial complex. The potential for the disastrous rise of
misplaced power exists and will persist.
-Dwight David Eisenhower, January 17, 1961

[Michele Simionato]

Bryan <be*****@yahoo. com> wrote in message news:<So36d.168 361$3l3.52363@a ttbi_s03>...

can someone explain to me why i get different values for the tm_yday and
tm_isdst values?

>>> import rfc822
>>> rfc822.parsedat e('Mar 1 01:03:59 2004') (2004, 3, 1, 1, 3, 59, 0, 0, 0)
>>> import time
>>> time.strptime(' Mar 1 01:03:59 2004', '%b %d %H:%M:%S %Y') (2004, 3, 1, 1, 3, 59, 0, 61, -1)
thanks,

bryan

I asked a similar question just few days ago. Here is the answer:

time.strptime(' Mar 1 01:03:59 2004 UTC', '%b %d %H:%M:%S %Y %Z')

(2004, 3, 1, 1, 3, 59, 0, 61, 0)

Michele Simionato

[Alex Martelli]

Steve Holden <st***@holdenwe b.com> wrote:
...

Note that strptime used only to be present if your platform's C library
provided it; though I can't say for sure that's changed I believe it
has. No idea when, though.

It's changed with 2.3 (thanks to Brett Cannon, who submitted his
pure-Python implementation of strptime, first published in the 1st
edition of the "Python Cookbook").
Alex