Skip to content

plistlib should create non-naÃŊve datetime objects #53502

Closed

Description

@wiml
mannequin
BPO 9256
Nosy @ronaldoussoren, @abalkin, @ned-deily, @bitdancer, @hynek
Files
  • plistdt.py: a simple test case
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/ronaldoussoren'
    closed_at = None
    created_at = <Date 2010-07-14.01:34:02.327>
    labels = ['OS-mac', 'type-bug', 'library']
    title = 'plistlib should create non-na\xc3\xafve datetime objects'
    updated_at = <Date 2014-06-30.00:02:22.179>
    user = 'https://bugs.python.org/wiml'

    bugs.python.org fields:

    activity = <Date 2014-06-30.00:02:22.179>
    actor = 'belopolsky'
    assignee = 'ronaldoussoren'
    closed = False
    closed_date = None
    closer = None
    components = ['Library (Lib)', 'macOS']
    creation = <Date 2010-07-14.01:34:02.327>
    creator = 'wiml'
    dependencies = []
    files = ['17993']
    hgrepos = []
    issue_num = 9256
    keywords = []
    message_count = 3.0
    messages = ['110249', '110250', '162471']
    nosy_count = 6.0
    nosy_names = ['ronaldoussoren', 'belopolsky', 'ned.deily', 'r.david.murray', 'wiml', 'hynek']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = 'needs patch'
    status = 'open'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue9256'
    versions = ['Python 3.5']

    Linked PRs

    Activity

    1. wiml commented on Jul 14, 2010

      wimlmannequin
      MannequinAuthor

      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 bpo-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).

    2. added
      type-bugAn unexpected behavior, bug, or error
      on Jul 14, 2010
    3. abalkin commented on Jul 14, 2010

      @abalkin
      Member

      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 bpo-7584.

    4. added
      stdlibStandard Library Python modules in the Lib/ directory
      on Jul 14, 2010
    5. self-assigned this
      on Jul 14, 2010
    6. bitdancer commented on Jun 7, 2012

      @bitdancer
      Member

      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.

    7. removed their assignment
      on Jun 30, 2014
    8. transferred this issue fromon Apr 10, 2022
    9. ronaldoussoren commented on May 21, 2022

      @ronaldoussoren
      Contributor

      I've added a feature label because changing this is a feature change and likely can only be done by adding a new option to plist parsers.

    10. added a commit that references this issue on Jan 1, 2024
    11. 3 remaining items

    12. added 2 commits that reference this issue on Jan 1, 2024
    13. added 2 commits that reference this issue on Jan 2, 2024
    14. hugovk commented on Jan 11, 2024

      @hugovk
      Member

      Triage: can this be re-closed following the recent fix PRs?

    15. added 3 commits that reference this issue on Jan 22, 2024
    16. added 3 commits that reference this issue on Feb 11, 2024
    17. added 3 commits that reference this issue on Sep 2, 2024
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Labels

    OS-macstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or errortype-featureA feature request or enhancement

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions