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.

Sign up for GitHub

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

Jump to bottom

feat(bigquery): switch all timestamp representations to int64 usec #9368

Merged
merged 4 commits into from Feb 5, 2024
Merged

feat(bigquery): switch all timestamp representations to int64 usec #9368

merged 4 commits into from Feb 5, 2024

Conversation

shollyman
Copy link
Contributor

With the recent resolutions to the discovery representation, we now correctly propagate the options for controlling timestamp representation. This PR forces all usages to lossless representations.

@shollyman
feat(bigquery): switch all timestamp representations to int64 usec
65b88c1 
With the recent resolutions to the discovery representation, we
now correctly propagate the options for controlling timestamp
representation.  This PR forces all usages to lossless representations.
@product-auto-label product-auto-label bot added size: xs Pull request size is extra small. api: bigquery Issues related to the BigQuery API. labels Feb 5, 2024
@product-auto-label product-auto-label bot added size: s Pull request size is small. and removed size: xs Pull request size is extra small. labels Feb 5, 2024
@product-auto-label product-auto-label bot added size: m Pull request size is medium. and removed size: s Pull request size is small. labels Feb 5, 2024
@shollyman shollyman marked this pull request as ready for review February 5, 2024 20:46
@shollyman shollyman requested review from a team as code owners February 5, 2024 20:46
alvarowolfx
alvarowolfx approved these changes Feb 5, 2024
View reviewed changes
Copy link
Contributor

@alvarowolfx alvarowolfx left a comment

Choose a reason for hiding this comment

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

I was double checking if that was going to affect Arrow parsing, as we also use the same convertBasicType method, but for Arrow timestamps we don't use it, so it's all good.

@shollyman shollyman added the automerge Merge the pull request once unit tests and other checks pass. label Feb 5, 2024
@gcf-merge-on-green gcf-merge-on-green bot merged commit 8c1fb7d into googleapis:main Feb 5, 2024
9 checks passed
@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 5, 2024
@release-please release-please bot mentioned this pull request Feb 5, 2024
Merged
@shollyman shollyman deleted the lossless branch February 5, 2024 22:01
gcf-merge-on-green bot pushed a commit that referenced this pull request Feb 6, 2024
@release-please
chore(main): release bigquery 1.59.0 (#9298)
62cc619 
🤖 I have created a release *beep* *boop*
---


## [1.59.0](https://togithub.com/googleapis/google-cloud-go/compare/bigquery/v1.58.0...bigquery/v1.59.0) (2024-02-06)


### Features

* **bigquery:** Add ExportDataStatstics to QueryStatistics ([#9371](https://togithub.com/googleapis/google-cloud-go/issues/9371)) ([261c8d9](https://togithub.com/googleapis/google-cloud-go/commit/261c8d944b53ac8953ea7d771c4bb50e4078d508))
* **bigquery:** Switch all timestamp representations to int64 usec ([#9368](https://togithub.com/googleapis/google-cloud-go/issues/9368)) ([8c1fb7d](https://togithub.com/googleapis/google-cloud-go/commit/8c1fb7d4728ebc3b21cb0d601952966dca9cd1e8))


### Bug Fixes

* **bigquery/storage/managedwriter:** Resolve data races ([#9360](https://togithub.com/googleapis/google-cloud-go/issues/9360)) ([fa31ec0](https://togithub.com/googleapis/google-cloud-go/commit/fa31ec0c0f04302a9713a9b1d3228bda2ba135c6))
* **bigquery:** Enable universe domain resolution options ([fd1d569](https://togithub.com/googleapis/google-cloud-go/commit/fd1d56930fa8a747be35a224611f4797b8aeb698))
* **bigquery:** Support more timestamp formats for query param ([#9236](https://togithub.com/googleapis/google-cloud-go/issues/9236)) ([cc98509](https://togithub.com/googleapis/google-cloud-go/commit/cc98509fc7961e3d3619b837d13e69f9621386e8)), refs [#9221](https://togithub.com/googleapis/google-cloud-go/issues/9221)

---
This PR was generated with [Release Please](https://togithub.com/googleapis/release-please). See [documentation](https://togithub.com/googleapis/release-please#release-please).
@alvarowolfx alvarowolfx mentioned this pull request Feb 7, 2024
Merged
@bombsimon bombsimon mentioned this pull request Feb 12, 2024
Closed
shollyman added a commit to shollyman/google-cloud-go that referenced this pull request Feb 12, 2024
@shollyman
fix(bigquery): align return time.Time values to UTC
66bb564 
The changes in googleapis#9368
changed the expectation that constructed time.Time objects would use UTC
time for location.  This PR returns to the old behavior by forcing the
values to be returned aligned to UTC time, and avoid using the local
timezone for construction.

Fixes: googleapis#9407
@shollyman shollyman mentioned this pull request Feb 12, 2024
Merged
shollyman added a commit that referenced this pull request Feb 12, 2024
@shollyman
fix(bigquery): align return time.Time values to UTC (#9411)
4ac005d 
The changes in #9368
changed the expectation that constructed time.Time objects would use UTC
time for location.  This PR returns to the old behavior by forcing the
values to be returned aligned to UTC time, and avoid using the local
timezone for construction.

Fixes: #9407
This was referenced Feb 13, 2024
Closed
Closed
Closed
@VDVsx VDVsx mentioned this pull request Mar 1, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@alvarowolfx alvarowolfx alvarowolfx approved these changes

Assignees
No one assigned
Labels
api: bigquery Issues related to the BigQuery API. size: m Pull request size is medium.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@shollyman @alvarowolfx