• Georgi Kodinov's avatar
    Bug #39920: MySQL cannot deal with Leap Second expression in string literal. · f56e43ce
    Georgi Kodinov authored
                      
    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
    f56e43ce
timezone3.result 2.21 KB