| Bug #108787 | UNIX_TIMESTAMP(NOW()) is lossy | ||
|---|---|---|---|
| Submitted: | 14 Oct 2022 18:51 | Modified: | 17 Oct 2022 6:50 |
| Reporter: | Domas Mituzas | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Server: DML | Severity: | S3 (Non-critical) |
| Version: | 8.0 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[17 Oct 2022 6:50]
MySQL Verification Team
Hello Domas, Thank you for the report and feedback. regards, Umesh
Description: if you select unix_timestamp() from now() (in order to get higher precision, for example), you will have wrong data in it during daylight time shifts. this looks familiar to stuff I reported before, but that was more than 12 years ago.... How to repeat: mysql> select unix_timestamp(now()), unix_timestamp(), unix_timestamp(now())-unix_timestamp() \G *************************** 1. row *************************** unix_timestamp(now()): 1667727948 unix_timestamp(): 1667724348 unix_timestamp(now())-unix_timestamp(): 3600 Suggested fix: annotate now() output with a timezone offset, or introduce a new suite of functions that output timezone offsets