Returning native datetime objects for Bucket/Blob time properties. by dhermes · Pull Request #807 · googleapis/google-cloud-python · GitHub

Note this was almost in #793 but dropped due to RFC3339 questions.

@craigcitro @thobrla can you vet an assumption for me? Will timestamps returned conform to

_GOOGLE_TIMESTAMP_FORMAT = '%Y-%m-%dT%H:%M:%S.%fZ'
# For example
TIME_DELETED = '2014-11-05T20:34:37.000Z'

I ask because '2014-11-05T20:34:37Z' is also totally valid according to RFC3339 and I'm wondering if we can get away with using datetime alone (and not having to use the strict-rfc3339 library for the full generality of RFC3339).

Changes Unknown when pulling 9f7d6fc on dhermes:use-native-datetime into * on GoogleCloudPlatform:master*.

I think this is true, but it is an implementation detail so it could break in the future; the discovery document only claims this is in RFC3339 format.

That being said, apitools just uses protorpc, which uses datetime exclusively. @craigcitro may be able to comment further; looking at the code we treat the timestamps as DateTimeFields, https://github.com/google/protorpc/blob/master/protorpc/message_types.py#L52, but these are in millisecond format, not RFC3339 and I can't find where it does the string conversion.

@thobrla The conversion happens in apitools

Ah; the responsible code is actually in protorpc, and that handles both kinds of string formats (using text search and strptime). That seems like a reasonable approach.

Yes, I'm cool doing that (only because we will end up requiring protorpc via apitools anyhow).

one more heads-up about timestamps: some newer APIs (eg pubsub) may return you timestamps with even more precision. i.e. down to the nanosecond. (see source here)

@craigcitro WAT? datetime doesn't support nanoseconds, so I suppose I should hold off. Oh Google, le sigh.

well, your fix is still good for storage. we can cross the next bridge when we come to it.

@craigcitro You mean this PR is good or the suggestion to use protorpc.util.decode_datetime?

As it were, I can confirm that the timezone support and the option of not having milliseconds (the only extra features) are not necessary.

From the discovery type documentation:

Type value	Format value	Meaning
string	date-time	An RFC3339 timestamp in UTC time. This is formatted as YYYY-MM-DDThh:mm:ss.fffZ. The milliseconds portion (".fff") is optional. Defined in the JSON Schema spec.

@tseaver I made an update to the unit tests and also made a slight tweak to the use of mtime in Blob.download_to_filename (was some repeated code).

PTAL

Changes Unknown when pulling 2645e1d on dhermes:use-native-datetime into * on GoogleCloudPlatform:master*.

LGTM

Returning native datetime objects for Bucket/Blob time properties.

🤖 I have created a release \*beep\* \*boop\* --- ### [0.42.2](https://www.github.com/googleapis/gapic-generator-python/compare/v0.42.1...v0.42.2) (2021-03-05) ### Bug Fixes * s/grpcAsync/grpc-async for gapic metadata ([#803](https://www.github.com/googleapis/gapic-generator-python/issues/803)) ([96f7864](https://www.github.com/googleapis/gapic-generator-python/commit/96f78640d90cf50c6b525924d14c6afe31874be6)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).

…age (#807) * chore: upgrade enchant packages in (Owlbot-controlled) docs Docker image Ubuntu Jammy doesn't have the enchant and libenchant1c2a packages. So, after googleapis/synthtool#1422 was merged, which switched the base image of the Dockerfile, it's been unable to install these packages. * 🦉 Updates from OwlBot post-processor See https://github.com/googleapis/repo-automation-bots/blob/main/packages/owl-bot/README.md Co-authored-by: Owl Bot <gcf-owl-bot[bot]@users.noreply.github.com> Co-authored-by: Mariatta Wijaya <Mariatta@users.noreply.github.com>

* fix: do not use the GAE APIs on gen2+ runtimes Currently, this library uses the App Engine API in all environments if it can be imported successfully. This assumption made sense when the API was only available on gen1, but this is no longer the case. See https://github.com/GoogleCloudPlatform/appengine-python-standard In order to comply with AIP-4115, we must treat GAE gen2+ as a "compute engine equivalent environment" even if the GAE APIs are importable. In other words, google.auth.default() must never return an app_engine.Credental on GAE gen2+.Currently, this library uses the App Engine API in all environments if it can be imported successfully. This assumption made sense when the API was only available on gen1, but this is no longer the case. See https://github.com/GoogleCloudPlatform/appengine-python-standard In order to comply with AIP-4115, we must treat GAE gen2+ as a "compute engine equivalent environment" even if the GAE APIs are importable. In other words, google.auth.default() should not return an app_engine.Credental on GAE gen2+. * blacken Co-authored-by: arithmetic1728 <58957152+arithmetic1728@users.noreply.github.com>

Source-Link: googleapis/synthtool@50db768 Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:e09366bdf0fd9c8976592988390b24d53583dd9f002d476934da43725adbb978

googlebot added the cla: yes This human has signed the Contributor License Agreement. label Apr 8, 2015

tseaver reviewed Apr 8, 2015
View reviewed changes

Comment thread gcloud/storage/test_blob.py Outdated

This comment was marked as spam.

Sign in to view

This comment was marked as spam.

Sign in to view

This comment was marked as spam.

Sign in to view

Returning native datetime objects for Bucket/Blob time properties.

2645e1d

dhermes force-pushed the use-native-datetime branch from 9f7d6fc to 2645e1d Compare April 9, 2015 16:54

dhermes added a commit that referenced this pull request Apr 9, 2015

Merge pull request #807 from dhermes/use-native-datetime

3f6ee7b

Returning native datetime objects for Bucket/Blob time properties.

dhermes merged commit 3f6ee7b into googleapis:master Apr 9, 2015

dhermes deleted the use-native-datetime branch April 9, 2015 17:56

dhermes mentioned this pull request Apr 9, 2015

Upgrading version to 0.5.0. #813

Merged

parthea pushed a commit that referenced this pull request Aug 21, 2025

chore(deps): update dependency tqdm to v4.66.5 (#807 )

2c70488

parthea pushed a commit that referenced this pull request Sep 16, 2025

chore(deps): update dependency tqdm to v4.66.5 (#807 )

f2f40d0

parthea pushed a commit that referenced this pull request Mar 6, 2026

test: add foreign key tests (#807 )

1e29bf5

parthea pushed a commit that referenced this pull request Mar 9, 2026

fix: fix rewrite object in CMEK enabled bucket (#807 )

33d0681

Returning native datetime objects for Bucket/Blob time properties. by dhermes · Pull Request #807 · googleapis/google-cloud-python · GitHub

Uh oh!

Returning native datetime objects for Bucket/Blob time properties. - #807

Returning native datetime objects for Bucket/Blob time properties.#807dhermes merged 1 commit intogoogleapis:mastergoogleapis/google-cloud-python:masterfrom dhermes:use-native-datetimedhermes/google-cloud-python:use-native-datetimeCopy head branch name to clipboard

Conversation

dhermes commented Apr 8, 2015

Uh oh!

coveralls commented Apr 8, 2015

Uh oh!

thobrla commented Apr 8, 2015

Uh oh!

This comment was marked as spam.

Uh oh!

This comment was marked as spam.

Uh oh!

This comment was marked as spam.

Uh oh!

dhermes commented Apr 8, 2015

Uh oh!

thobrla commented Apr 8, 2015

Uh oh!

dhermes commented Apr 8, 2015

Uh oh!

craigcitro commented Apr 8, 2015

Uh oh!

dhermes commented Apr 9, 2015

Uh oh!

craigcitro commented Apr 9, 2015

Uh oh!

dhermes commented Apr 9, 2015

Uh oh!

dhermes commented Apr 9, 2015

Uh oh!

coveralls commented Apr 9, 2015

Uh oh!

tseaver commented Apr 9, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Returning native datetime objects for Bucket/Blob time properties.#807
dhermes merged 1 commit into
googleapis:masterfrom
dhermes:use-native-datetime