[issue9256] plistlib should create non-naïve datetime objects

Changes by Alexander Belopolsky : -- assignee: -> ronaldoussoren components: +Macintosh ___ Python tracker ___ ___ Python-bugs-list ma

[issue9256] plistlib should create non-naïve datetime objects

Changes by Alexander Belopolsky : -- assignee: belopolsky -> nosy: +hynek, ned.deily, ronaldoussoren versions: +Python 3.5 -Python 3.2 ___ Python tracker ___

[issue9256] plistlib should create non-naïve datetime objects

R. David Murray added the comment: 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 t

[issue9256] plistlib should create non-naïve datetime objects

Changes by Alexander Belopolsky : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue9256] plistlib should create non-naïve datetime objects

Alexander Belopolsky added the comment: Yes, parsing 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 75

[issue9256] plistlib should create non-naïve datetime objects

New submission from Wim : The plistlib module parses elements in the plist into datetime objects. (This is good.) However, it produces naïve datetimes, even though the elements include an explicit timezone specification ('Z' for UTC, since they're in ISO 8601 format). Now that issue 5094 ha