New submission from Wim <w...@hhhh.org>:
The plistlib module parses <date> elements in the plist into datetime objects.
(This is good.) However, it produces naïve datetimes, even though the <date>
elements include an explicit timezone specification ('Z' for UTC, since they're
in ISO 8601 format).
Now that issue 5094 has been fixed, this should be a pretty trivial thing to
fix— just pass tzinfo=UTC when creating the datetime (since the regex it uses
won't even accept a date that doesn't have the 'Z' suffix, this will be
correct).
As an aside: RFC 3339 section 4.3 suggests a convention for distinguishing
between "timestamps in UTC" and "timestamps which happen to be defined in terms
of UTC, but don't really live in any particular timezone". The python datetime
module is not currently able to make this distinction AFAIK, but even though
the plist date strings don't follow the RFC 3339 convention, they are most
accurately described as having an unknown local offset (like POSIX timestamps,
they are UTC-referenced but cannot carry local-timezone info).
----------
files: plistdt.py
messages: 110249
nosy: wiml
priority: normal
severity: normal
status: open
title: plistlib should create non-naïve datetime objects
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file17993/plistdt.py
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9256>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
