-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
Open
Labels
3.8 (EOL)end of lifeend of lifeOS-macstdlibPython modules in the Lib dirPython modules in the Lib dirtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Description
BPO | 41083 |
---|---|
Nosy | @ronaldoussoren, @tiran, @ned-deily, @shields-fn |
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 = None
closed_at = None
created_at = <Date 2020-06-22.22:42:45.413>
labels = ['OS-mac', '3.8', 'type-bug', 'library']
title = "plistlib can't decode date from year 0"
updated_at = <Date 2020-06-23.17:24:51.579>
user = 'https://github.com/shields-fn'
bugs.python.org fields:
activity = <Date 2020-06-23.17:24:51.579>
actor = 'shields-fn'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)', 'macOS']
creation = <Date 2020-06-22.22:42:45.413>
creator = 'shields-fn'
dependencies = []
files = []
hgrepos = []
issue_num = 41083
keywords = []
message_count = 5.0
messages = ['372131', '372151', '372152', '372159', '372185']
nosy_count = 4.0
nosy_names = ['ronaldoussoren', 'christian.heimes', 'ned.deily', 'shields-fn']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue41083'
versions = ['Python 3.8']
Linked PRs
Metadata
Metadata
Assignees
Labels
3.8 (EOL)end of lifeend of lifeOS-macstdlibPython modules in the Lib dirPython modules in the Lib dirtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Activity
shields-fn commentedon Jun 22, 2020
On macOS 10.5.5:
/tmp $ defaults export com.apple.security.KCN -
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-/Apple/DTD PLIST 1.0/EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"\>
<plist version="1.0">
<dict>
<key>absentCircleWithNoReason</key>
<false/>
<key>applicationDate</key>
<date>0000-12-30T00:00:00Z</date>
<key>lastCircleStatus</key>
<integer>-1</integer>
<key>lastWritten</key>
<date>2019-10-15T17:23:33Z</date>
<key>pendingApplicationReminder</key>
<date>4001-01-01T00:00:00Z</date>
<key>pendingApplicationReminderInterval</key>
<integer>86400</integer>
</dict>
</plist>
/tmp $ cat plist_date_reduction.py
#!/usr/bin/env python3
tiran commentedon Jun 23, 2020
There is no year 0. It does not exist. The year after 1 BC is the year 1 AD.
tiran commentedon Jun 23, 2020
By the way most datetime libraries will give you incorrect values for dates before 1582, 1752, 1926, 1949 or any dates in that range depending on your country and the predominant religion of your country, county, state, or principality. Dates before 1970 are generally problematic unless the date format also references a calendar system.
It's ... messy.
ronaldoussoren commentedon Jun 23, 2020
Year 0 does exist in ISO 8601 though, but that wouldn't help us here as year 0 in that standard is year 1 BCE which is not representable in Python's datetime module.
I'm not sure what we can do about this. The best we could do with plistlib is probably to add an option to either set unrepresentable dates to None or represent those dates as strings.
A more comprehensive fix is to change datetime to be able to represent these dates, but that's a much larger change that likely requires a PEP.
shields-fn commentedon Jun 23, 2020
You're correct that there is no year 0, but as you see Apple does use <date>0000-12-30T00:00:00Z</date> in their plists. I did not set that in order to test plistlib; it's what I found on my system.
If it's a goal that plistlib be able to parse system-generated plists and round-trip them to an equivalent serialization -- and I think that should be a goal -- then using strings or None also won't work. Maybe there could be a plistlib.Datetime for dates which are outside what datetime can represent?
zitterbewegung commentedon Apr 24, 2023
This hasn't been accepted and opened still for three years and also is likely a change that would require a PEP and no PEP addressing this hasn't been created. IMHO this should be closed.
4 remaining items