Skip to content

bpo-42401: Fix parsing and writing of the date timezone. #23384

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

jcbertin
Copy link

@jcbertin jcbertin commented Nov 19, 2020

The plistlib library does not write dates correctly due to its timezone naive date management.
You can test it by running this gist: https://gist.github.com/jcbertin/fedc115ea8122bec9953aa11041294eb

This PR fix it for both the writer and the parser. However, for the parser, it keeps the actual behavior for compatibility reason but adds an option to correctly decode timezone aware dates.

https://bugs.python.org/issue42401

@the-knights-who-say-ni
Copy link

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

CLA Missing

Our records indicate the following people have not signed the CLA:

@jcbertin

For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Dec 20, 2020
Copy link
Contributor

@MaxwellDupre MaxwellDupre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why have you set _MACOS_EPOCH and _MACOS_EPOCH_NAIVE to 2001,1,1?
When I googled it said same as Unix epoch 1970,1,1.
Also, I note that there are failed tests, can you check and fix please?

@micolous
Copy link

Driving by as I've also hit this same bug...

Why have you set _MACOS_EPOCH and _MACOS_EPOCH_NAIVE to 2001,1,1? When I googled it said same as Unix epoch 1970,1,1.

I don't know where you saw documentation indicating otherwise, because CFBinaryPList.c's implementation of binary CFDate calls CFDateGetAbsoluteTime, which per the documentation:

Absolute time is measured in seconds relative to the absolute reference date of Jan 1 2001 00:00:00 GMT. A positive value represents a date after the reference date, a negative value represents a date before it. For example, the absolute time -32940326 is equivalent to December 16th, 1999 at 17:54:34.

The existing code already set the epoch to 2001-01-01.

It's unclear what the test failures actually are here, though, because the build logs have long-expired as this patch was unreviewed for a while. A test for this new feature would be useful, though. :)

@github-actions github-actions bot removed the stale Stale PR or inactive for long period of time. label Aug 1, 2022
@ghost
Copy link

ghost commented Nov 28, 2022

The following commit authors need to sign the Contributor License Agreement:

Click the button to sign:
CLA not signed

@ronaldoussoren
Copy link
Contributor

#113363 implements an option to read and write timezone aware datetime values and with that this PR is no longer necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants