[issue41083] plistlib can't decode date from year 0

Michael Shields added the comment: You're correct that there is no year 0, but as you see Apple does use -12-30T00:00:00Z 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

[issue41083] plistlib can't decode date from year 0

Ronald Oussoren added the comment: 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

[issue41083] plistlib can't decode date from year 0

Christian Heimes added the comment: 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

[issue41083] plistlib can't decode date from year 0

Christian Heimes added the comment: There is no year 0. It does not exist. The year after 1 BC is the year 1 AD. -- nosy: +christian.heimes ___ Python tracker ___

[issue41083] plistlib can't decode date from year 0

Change by Karthikeyan Singaravelan : -- components: +macOS nosy: +ned.deily, ronaldoussoren ___ Python tracker ___ ___

[issue41083] plistlib can't decode date from year 0

New submission from Michael Shields : On macOS 10.5.5: /tmp $ defaults export com.apple.security.KCN - http://www.apple.com/DTDs/PropertyList-1.0.dtd;> absentCircleWithNoReason applicationDate -12-30T00:00:00Z lastCircleStatus -1