classification
Title: plistlib should create non-naïve datetime objects
Type: behavior Stage: needs patch
Components: Library (Lib), macOS Versions: Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: ronaldoussoren Nosy List: belopolsky, hynek, ned.deily, r.david.murray, ronaldoussoren, wiml
Priority: normal Keywords:

Created on 2010-07-14 01:34 by wiml, last changed 2014-06-30 00:02 by belopolsky.

Files
File name Uploaded Description Edit
plistdt.py wiml, 2010-07-14 01:34 a simple test case
Messages (3)
msg110249 - (view) Author: Wim (wiml) Date: 2010-07-14 01:34
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).
msg110250 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-07-14 01:42
Yes, parsing <date> elements ending with 'Z' into aware datetime objects makes perfect sense, but this should be done carefully because doing so will break any code that mixes the result with naive datetimes.

There is a lengthy RFC 3339 discussion in issue 7584.
msg162471 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-06-07 12:48
An alternative is to do what the email package in 3.3 does, and treat naive datetimes as exactly "UTC referenced but with no information as to what local timezone they originated in".  Either way, a program using the plistlib is going to have to know about this and handle the distinction itself, since as you say datetime doesn't have a way to make this differentiation (other than naive vs aware).  So it needs to be documented clearly if it isn't already.
History
Date User Action Args
2014-06-30 00:02:22belopolskysetassignee: ronaldoussoren
components: + macOS
2014-06-30 00:00:52belopolskysetassignee: belopolsky -> (no value)

nosy: + ronaldoussoren, ned.deily, hynek
versions: + Python 3.5, - Python 3.2
2012-06-07 12:48:48r.david.murraysetmessages: + msg162471
2012-06-07 03:52:03belopolskysetnosy: + r.david.murray
2010-07-14 01:42:11belopolskysetassignee: belopolsky
components: + Library (Lib)
versions: + Python 3.2, - Python 2.6, Python 2.5
nosy: + belopolsky

messages: + msg110250
stage: needs patch
2010-07-14 01:34:02wimlcreate