Skip to content
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

fix: correctly decode times without microseconds #375

Merged
merged 5 commits into from Feb 10, 2021

Conversation

tritone
Copy link
Contributor

@tritone tritone commented Feb 9, 2021

Currently custom_time is not being decoded correctly if the value
has a zero in the microseconds field. This fixes the issue for
custom_time as well as elsewhere by replacing _datetime_to_rfc3339
with _rfc3339_nanos_to_datetime.

Fixes #363

@google-cla google-cla bot added the cla: yes This human has signed the Contributor License Agreement. label Feb 9, 2021
@product-auto-label product-auto-label bot added the api: storage Issues related to the googleapis/python-storage API. label Feb 9, 2021
Currently custom_time is not being decoded correctly if the value
has a zero in the microseconds field. This fixes the issue for
custom_time as well as elsewhere by replacing _datetime_to_rfc3339
with _rfc3339_nanos_to_datetime.

Fixes googleapis#363
@tritone tritone changed the title fix: custom_time decoding without microseconds fix: correctly decode times without microseconds Feb 9, 2021
@tritone tritone marked this pull request as ready for review February 9, 2021 15:20
@tritone tritone requested a review from a team February 9, 2021 15:20
@frankyn frankyn requested a review from a team as a code owner February 9, 2021 20:34
@tseaver tseaver added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Feb 9, 2021
@yoshi-kokoro yoshi-kokoro removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Feb 9, 2021
@tseaver
Copy link
Contributor

tseaver commented Feb 9, 2021

@tritone, @frankyn Seems like we need one or more unit test which assert this change in behavior?

@frankyn
Copy link
Member

frankyn commented Feb 9, 2021

Thanks @tseaver. Did we miss a coverage check?

@tritone
Copy link
Contributor Author

tritone commented Feb 9, 2021

@tritone, @frankyn Seems like we need one or more unit test which assert this change in behavior?

The system test does cover the case that was failing before and ensures that we're correctly parsing the timestamp that GCS returns. I haven't dug into how this code is unit tested currently but I can look into it if you think it would help.

@andrewsg andrewsg added the automerge Merge the pull request once unit tests and other checks pass. label Feb 10, 2021
@gcf-merge-on-green gcf-merge-on-green bot merged commit 37a1eb5 into googleapis:master Feb 10, 2021
@gcf-merge-on-green gcf-merge-on-green bot removed the automerge Merge the pull request once unit tests and other checks pass. label Feb 10, 2021
cojenco pushed a commit to cojenco/python-storage that referenced this pull request Oct 13, 2021
Currently custom_time is not being decoded correctly if the value
has a zero in the microseconds field. This fixes the issue for
custom_time as well as elsewhere by replacing _datetime_to_rfc3339
with _rfc3339_nanos_to_datetime.

Fixes googleapis#363
cojenco pushed a commit to cojenco/python-storage that referenced this pull request Oct 13, 2021
Currently custom_time is not being decoded correctly if the value
has a zero in the microseconds field. This fixes the issue for
custom_time as well as elsewhere by replacing _datetime_to_rfc3339
with _rfc3339_nanos_to_datetime.

Fixes googleapis#363
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: storage Issues related to the googleapis/python-storage API. cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Accessing blob.custom_time errors on 0 microsecond timestamp
5 participants