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

datastore: civil package types are loaded incorrectly when local machine timezone is not UTC #3360

Closed
dnerdy opened this issue Dec 3, 2020 · 3 comments · Fixed by #3376
Closed
Assignees
Labels
api: datastore Issues related to the Datastore API. priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@dnerdy
Copy link

dnerdy commented Dec 3, 2020

Client

Datastore

Environment

Any

Go Environment

$ go version
go version go1.14.12 darwin/amd64
$ go env
[I believe this is unrelated.]

Code

The pre-existing TestLoadToInterface test fails when run on a machine that has a timezone set to a non UTC timezone.

cd datastore
go test ./... -run TestLoadToInterface

Also, the TestLoadToInterface/struct_with_civil.Date would fail when run on a machine set to Pacific time if the test timestamp was 1605504600 (11/16/2020 @ 5:30am UTC) instead of 1605474000 (11/15/2020 @ 9:00pm UTC).

Expected behavior

I would expect the above tests to pass when run on a machine with any non-UTC timezone.

Actual behavior

--- FAIL: TestLoadToInterface (0.00s)
    --- FAIL: TestLoadToInterface/struct_with_civil.DateTime (0.00s)
        load_test.go:565: Mismatch: got - want +
              &struct{ DateTime civil.DateTime }{
              	DateTime: civil.DateTime{
              		Date: civil.Date{
              			Year:  2020,
              			Month: s"November",
            - 			Day:   15,
            + 			Day:   16,
              		},
              		Time: civil.Time{
            - 			Hour:       21,
            + 			Hour:       5,
              			Minute:     30,
              			Second:     0,
              			Nanosecond: 0,
              		},
              	},
              }
    --- FAIL: TestLoadToInterface/struct_with_civil.Time (0.00s)
        load_test.go:565: Mismatch: got - want +
              &struct{ Time civil.Time }{
              	Time: civil.Time{
            - 		Hour:       21,
            + 		Hour:       5,
              		Minute:     30,
              		Second:     0,
              		Nanosecond: 0,
              	},
              }
FAIL
FAIL	cloud.google.com/go/datastore	0.869s
ok  	cloud.google.com/go/datastore/admin/apiv1	0.559s [no tests to run]
?   	cloud.google.com/go/datastore/internal/gaepb	[no test files]
FAIL

(Also note the comment above about how TestLoadToInterface/struct_with_civil.Date also fails under some circumstances).

Additional context

I left a common on #3202 with information about how the loading can be corrected.

cc @codyoss

@dnerdy dnerdy added the triage me I really want to be triaged. label Dec 3, 2020
@product-auto-label product-auto-label bot added the api: datastore Issues related to the Datastore API. label Dec 3, 2020
@codyoss
Copy link
Member

codyoss commented Dec 3, 2020

Thanks!

@tritone tritone added priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. and removed triage me I really want to be triaged. labels Dec 7, 2020
@tritone
Copy link
Contributor

tritone commented Dec 7, 2020

@dnerdy let me know if this fix did the trick for you!

@dnerdy
Copy link
Author

dnerdy commented Dec 7, 2020

Looks good 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: datastore Issues related to the Datastore API. priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants