-
Notifications
You must be signed in to change notification settings - Fork 117
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
tapdb: fix time zone issue with timestamps #532
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🦚
Only request is some additional detail in the commit message body:
- Why did the comparison of the UTC vs localized timestamps encounter an issue here?
- Why didn't the db translation layer handle normalizing the timestamps?
- For all the other areas we use timestamps, do we always need to map them to UTC before inserting?
@@ -1682,7 +1682,7 @@ func (a *AssetStore) LeaseCoins(ctx context.Context, leaseOwner [32]byte, | |||
err = q.UpdateUTXOLease(ctx, UpdateUTXOLease{ | |||
LeaseOwner: leaseOwner[:], | |||
LeaseExpiry: sql.NullTime{ | |||
Time: expiry, | |||
Time: expiry.UTC(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 for doing this at the lowest level.
Because sqlc by default just uses the time.Time.String() method to turn a timestamp into the DB value, the time zone of the timestamp has an impact as any SQL query would basically be a string comparison that doesn't look at the time zone at all. For example: WHERE a < b Would be true for a = '2023-09-26 14:00:00 GMT-8' (22:00 local time) a = '2023-09-26 15:00:00 UTC' (15:00 local time) Even though 10pm is clearly after 3pm. To fix this, we explicitly call .UTC() on any time.Time we use in any SQL query. The only instances where that was not yet the case in the whole tapdb package were the newly added queries for UTXO leases. It seems that with a later release of the sqlite driver we could customize this behavior of how a timestamp is being formatted. But for now the .UTC() workaround should work as well.
c8ba4a1
to
05e8ae1
Compare
Added a commit message to clarify on this. It looks like we could customize this by setting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good - didn't see any other use of UTC()
in other tests.
Fixes an issue where unit tests would fail when being run in certain time zones.