Time Zone Leap Second Support - Oracle 5.0 Reference Manual

| CONVERT_TZ('2007-03-11 2:00:00','US/Eastern','US/Central') |
+------------------------------------------------------------+
| 2007-03-11 01:00:00
+------------------------------------------------------------+
mysql> SELECT CONVERT_TZ('2007-03-11 3:00:00','US/Eastern','US/Central');
+------------------------------------------------------------+
| CONVERT_TZ('2007-03-11 3:00:00','US/Eastern','US/Central') |
+------------------------------------------------------------+
| 2007-03-11 02:00:00
+------------------------------------------------------------+
After updating the tables, you should see the correct result:
mysql> SELECT CONVERT_TZ('2007-03-11 2:00:00','US/Eastern','US/Central');
+------------------------------------------------------------+
| CONVERT_TZ('2007-03-11 2:00:00','US/Eastern','US/Central') |
+------------------------------------------------------------+
| 2007-03-11 01:00:00
+------------------------------------------------------------+
mysql> SELECT CONVERT_TZ('2007-03-11 3:00:00','US/Eastern','US/Central');
+------------------------------------------------------------+
| CONVERT_TZ('2007-03-11 3:00:00','US/Eastern','US/Central') |
+------------------------------------------------------------+
| 2007-03-11 01:00:00
+------------------------------------------------------------+

10.6.2. Time Zone Leap Second Support

Before MySQL 5.0.74, if the operating system is configured to return leap seconds from OS time
calls or if the MySQL server uses a time zone definition that has leap seconds, functions such as
[926]
NOW()
are inserted into a table, they would be dumped as is by
reloaded, leading to backup/restore problems.
As of MySQL 5.0.74, leap second values are returned with a time part that ends with :59:59. This
means that a function such as
seconds during the leap second. It remains true that literal temporal values having a time part that ends
with
:59:60
If it is necessary to search for
results may be obtained if you use a comparison with
following example demonstrates this. It changes the local time zone to UTC so there is no difference
between internal values (which are in UTC) and displayed values (which have time zone correction
applied).
mysql> CREATE TABLE t1 (
-> a INT,
-> ts TIMESTAMP DEFAULT NOW(),
-> PRIMARY KEY (ts)
-> );
Query OK, 0 rows affected (0.01 sec)
mysql> -- change to UTC
mysql> SET time_zone = '+00:00';
Query OK, 0 rows affected (0.00 sec)
mysql> -- Simulate NOW() = '2008-12-31 23:59:59'
mysql> SET timestamp = 1230767999;
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO t1 (a) VALUES (1);
Query OK, 1 row affected (0.00 sec)
mysql> -- Simulate NOW() = '2008-12-31 23:59:60'
mysql> SET timestamp = 1230768000;
Query OK, 0 rows affected (0.00 sec)
Time Zone Leap Second Support
could return a value having a time part that ends with
NOW()
or are considered invalid.
:59:61
TIMESTAMP
mysqldump
[926] can return the same value for two or three consecutive
values one second before the leap second, anomalous
'YYYY-MM-DD hh:mm:ss'
820
|
|
|
|
or :59:61. If such values
:59:60
but considered invalid when
values. The