summaryrefslogtreecommitdiff
path: root/mysql-test/std_data/Moscow_leap
Commit message (Collapse)AuthorAgeFilesLines
* Bug #39920: MySQL cannot deal with Leap Second expression in string literal.Georgi Kodinov2008-12-011-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updated MySQL time handling code to react correctly on UTC leap second additions. MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc will return :59:59 instead of :59:60 or 59:61. As a result the reader will receive :59:59 for 2 or 3 consecutive seconds during the leap second. This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds. But note that when converting the value returned by UNIX_TIMESTAMP() to broken down time the correction of leap seconds will still be applied. Note that this fix will make a difference *only* if the OS is specially configured to return leap seconds from the OS time calls or when using a MySQL time zone defintion that has leap seconds. Even after this change date/time literals (or other broken down time representations) with leap seconds (ending on :59:60 or 59:61) will still be considered illegal and discarded by the server with an error or a warning depending on the sql mode. Added a test case to demonstrate the effect of the fix. mysql-test/r/timezone3.result: Bug #39920: test case mysql-test/std_data/Moscow_leap: Bug #39920: updated the Moscow time zone to Dr. Olson's tzdata 2008i to accomodate for the 2008 leap second mysql-test/t/timezone3.test: Bug #39920: test case sql/tztime.cc: Bug #39920: adjust leap seconds (:60 or :61) to :59 sql/tztime.h: Bug #39920: adjust leap seconds (:60 or :61) to :59
* Fix for bug #6387 "Queried timestamp values do not match the insertedunknown2004-11-031-0/+0
value if server runs in time zone with leap seconds". Now in my_gmt_sec() function we take into account difference between our target and estimation in seconds part. mysql-test/Makefile.am: Added mysql-test/std_data/Moscow_leap reuired by new timezone3.test to source distribution. sql/time.cc: my_gmt_sec(): When comparing our target broken-down datetime t value and proper representation of our estimation *l_time we should take into account that they could differ in second part if we have time zone leap seconds. Also added comments about some assumptions used in this function.