Skip to content
This repository was archived by the owner on Mar 31, 2026. It is now read-only.

fix: correctly decode times without microseconds - #375

Merged
gcf-merge-on-green[bot] merged 5 commits into
googleapis:masterfrom
tritone:customtime-micros
Feb 10, 2021
Merged

fix: correctly decode times without microseconds#375
gcf-merge-on-green[bot] merged 5 commits into
googleapis:masterfrom
tritone:customtime-micros

Conversation

@tritone

@tritonetritone commented Feb 9, 2021

Copy link
Copy Markdown
Contributor

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-clagoogle-claBot added the cla: yes This human has signed the Contributor License Agreement. label Feb 9, 2021
@product-auto-labelproduct-auto-labelBot 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.
Fixesgoogleapis#363
@tritonetritone changed the title fix: custom_time decoding without microsecondsfix: correctly decode times without microsecondsFeb 9, 2021
@tritone
tritone marked this pull request as ready for review February 9, 2021 15:20
@tritone
tritone requested a review from a teamFebruary 9, 2021 15:20
@frankyn
frankyn requested a review from a teamFebruary 9, 2021 20:34
@tseavertseaver added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Feb 9, 2021
@yoshi-kokoroyoshi-kokoro removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Feb 9, 2021
@tseaver

Copy link
Copy Markdown
Contributor

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

@frankyn

Copy link
Copy Markdown
Contributor

Thanks @tseaver. Did we miss a coverage check?

@tritone

Copy link
Copy Markdown
ContributorAuthor

@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.

@andrewsgandrewsg 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-greenBot merged commit 37a1eb5 into googleapis:masterFeb 10, 2021
@gcf-merge-on-greengcf-merge-on-greenBot 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.
Fixesgoogleapis#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.
Fixesgoogleapis#363
@release-pleaserelease-pleaseBot mentioned this pull request Jan 12, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

api: storageIssues related to the googleapis/python-storage API.cla: yesThis 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

@tritone@tseaver@frankyn@andrewsg@yoshi-kokoro