-
Notifications
You must be signed in to change notification settings - Fork 46
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
Precision of TIMESTAMP type is different #73
Comments
any updates on this issue? we're also running into this. |
I'm facing the same issue. Interestingly, this seems to be working correctly in the Spanner Emulator: |
I'm facing the same issue. |
We are looking into it and will back soon. |
any updates? I faced the same issue |
Root cause is in ZetaSQL reference implementation, when calling There is a workaround though: SELECT CAST('2022-03-31T23:59:59.999999999Z' AS TIMESTAMP) totally works |
I raised a pull request which fixes |
Hit the same issue. Here's a small reproducer: DROP TABLE IF EXISTS Demo;
CREATE TABLE Demo (
Id INT64 NOT NULL,
Time TIMESTAMP NOT NULL
) PRIMARY KEY (Id);
INSERT INTO Demo (Id, Time) VALUES (1, TIMESTAMP '2024-10-16 04:03:54.939599300-00');
SELECT * FROM Demo WHERE Time = (SELECT MAX(Time) FROM Demo);
-- result is empty
SELECT STRING(MAX(Time)) FROM Demo;
-- result is "2024-10-15 21:03:54.939599-07" |
On cloud-spanner-emulator, the following SQL will get the error
spanner: code = "OutOfRange", desc = "Invalid timestamp: '2022-03-31T23:59:59.999999999Z'"
However, Cloud Spanner does not return any error.
Also the emulator accept nanoseconds level value as TIMESTAMP type, but
MAX()
andMIN()
returns microseconds's one.For example, if
SomethingTable
hasCreatedAt TIMESTAMP NOT NULL
column and value of2022-03-31T14:59:59.999999999Z
was inserted.The following SQL returns
2022-03-31T14:59:59.999999999Z
.However, the following SQL returns
2022-03-31T14:59:59.999999Z
.The text was updated successfully, but these errors were encountered: