Author: paul
Date: 2008-12-23 03:50:19 +0100 (Tue, 23 Dec 2008)
New Revision: 12984
Log:
r36937@frost: paul | 2008-12-22 20:52:16 -0500
Move 5.0 leap second material to correct section
(bad patch)
Modified:
trunk/refman-5.0/internationalization.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:40875
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:36931
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:35335
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:40875
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:36937
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:35335
Modified: trunk/refman-5.0/internationalization.xml
===================================================================
--- trunk/refman-5.0/internationalization.xml 2008-12-23 00:15:09 UTC (rev 12983)
+++ trunk/refman-5.0/internationalization.xml 2008-12-23 02:50:19 UTC (rev 12984)
Changed blocks: 2, Lines Added: 81, Lines Deleted: 81; 6683 bytes
@@ -7359,87 +7359,6 @@
1 row in set (0.00 sec)
</programlisting>
- <para>
- 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 <literal role="func">NOW()</literal> could return a
- value having a time part that ends with
- <literal>:59:60</literal> or <literal>:59:61</literal>. If such
- values are inserted into a table, they would be dumped as is by
- <command>mysqldump</command> but considered invalid when
- reloaded, leading to backup/restore problems.
- </para>
-
- <para>
- As of MySQL 5.0.74, leap second values are returned with a time
- part that ends with <literal>:59:59</literal>. This means that a
- function such as <literal role="func">NOW()</literal> can return
- the same value for two or three consecutive seconds during the
- leap second. It remains true that literal temporal values having
- a time part that ends with <literal>:59:60</literal> or
- <literal>:59:61</literal> are considered invalid.
- </para>
-
- <para>
- If it is necessary to search for
- <literal role="type">TIMESTAMP</literal> values one second
- before the leap second, anomalous results may be obtained if you
- use a comparison with <literal>'YYYY-MM-DD hh:mm:ss'</literal>
- values:
- </para>
-
-<programlisting>
-<!--
-mysql> DROP TABLE IF EXISTS t1;
-Query OK, 0 rows affected (0.06 sec)
--->
-mysql> <userinput>CREATE TABLE t1 (a INT, ts TIMESTAMP DEFAULT NOW(), PRIMARY KEY (ts));</userinput>
-Query OK, 0 rows affected (0.11 sec)
-
-mysql> <userinput># Simulate NOW() = '2009-01-01 02:59:59'</userinput>
-mysql> <userinput>SET timestamp = 1230768022;</userinput>
-Query OK, 0 rows affected (0.00 sec)
-
-mysql> <userinput>INSERT INTO t1 (a) VALUES (1);</userinput>
-Query OK, 1 row affected (0.07 sec)
-
-mysql> <userinput># Simulate NOW() = '2009-01-01 02:59:60'</userinput>
-mysql> <userinput>SET timestamp = 1230768023;</userinput>
-Query OK, 0 rows affected (0.00 sec)
-
-mysql> <userinput>INSERT INTO t1 (a) VALUES (2);</userinput>
-Query OK, 1 row affected (0.02 sec)
-
-mysql> <userinput>SELECT * FROM t1;</userinput>
-+------+---------------------+
-| a | ts |
-+------+---------------------+
-| 1 | 2008-12-31 18:00:22 |
-| 2 | 2008-12-31 18:00:23 |
-+------+---------------------+
-2 rows in set (0.02 sec)
-
-mysql> <userinput>SELECT * FROM t1 WHERE ts = '2009-01-01 02:59:59';</userinput>
-Empty set (0.03 sec)
-</programlisting>
-
- <para>
- To work around this, you can use a comparison based on the UTC
- value actually stored in column, which has the leap second
- correction applied:
- </para>
-
-<programlisting>
-mysql> <userinput>SELECT * FROM t1 WHERE UNIX_TIMESTAMP(ts) = 1230768023;</userinput>
-+------+---------------------+
-| a | ts |
-+------+---------------------+
-| 2 | 2008-12-31 18:00:23 |
-+------+---------------------+
-1 row in set (0.02 sec)
-</programlisting>
-
</section>
</section>
@@ -7998,6 +7917,87 @@
<secondary>leap seconds</secondary>
</indexterm>
+ <para>
+ 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 <literal role="func">NOW()</literal> could return a
+ value having a time part that ends with
+ <literal>:59:60</literal> or <literal>:59:61</literal>. If such
+ values are inserted into a table, they would be dumped as is by
+ <command>mysqldump</command> but considered invalid when
+ reloaded, leading to backup/restore problems.
+ </para>
+
+ <para>
+ As of MySQL 5.0.74, leap second values are returned with a time
+ part that ends with <literal>:59:59</literal>. This means that a
+ function such as <literal role="func">NOW()</literal> can return
+ the same value for two or three consecutive seconds during the
+ leap second. It remains true that literal temporal values having
+ a time part that ends with <literal>:59:60</literal> or
+ <literal>:59:61</literal> are considered invalid.
+ </para>
+
+ <para>
+ If it is necessary to search for
+ <literal role="type">TIMESTAMP</literal> values one second
+ before the leap second, anomalous results may be obtained if you
+ use a comparison with <literal>'YYYY-MM-DD hh:mm:ss'</literal>
+ values:
+ </para>
+
+<programlisting>
+<!--
+mysql> DROP TABLE IF EXISTS t1;
+Query OK, 0 rows affected (0.06 sec)
+-->
+mysql> <userinput>CREATE TABLE t1 (a INT, ts TIMESTAMP DEFAULT NOW(), PRIMARY KEY (ts));</userinput>
+Query OK, 0 rows affected (0.11 sec)
+
+mysql> <userinput># Simulate NOW() = '2009-01-01 02:59:59'</userinput>
+mysql> <userinput>SET timestamp = 1230768022;</userinput>
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> <userinput>INSERT INTO t1 (a) VALUES (1);</userinput>
+Query OK, 1 row affected (0.07 sec)
+
+mysql> <userinput># Simulate NOW() = '2009-01-01 02:59:60'</userinput>
+mysql> <userinput>SET timestamp = 1230768023;</userinput>
+Query OK, 0 rows affected (0.00 sec)
+
+mysql> <userinput>INSERT INTO t1 (a) VALUES (2);</userinput>
+Query OK, 1 row affected (0.02 sec)
+
+mysql> <userinput>SELECT * FROM t1;</userinput>
++------+---------------------+
+| a | ts |
++------+---------------------+
+| 1 | 2008-12-31 18:00:22 |
+| 2 | 2008-12-31 18:00:23 |
++------+---------------------+
+2 rows in set (0.02 sec)
+
+mysql> <userinput>SELECT * FROM t1 WHERE ts = '2009-01-01 02:59:59';</userinput>
+Empty set (0.03 sec)
+</programlisting>
+
+ <para>
+ To work around this, you can use a comparison based on the UTC
+ value actually stored in column, which has the leap second
+ correction applied:
+ </para>
+
+<programlisting>
+mysql> <userinput>SELECT * FROM t1 WHERE UNIX_TIMESTAMP(ts) = 1230768023;</userinput>
++------+---------------------+
+| a | ts |
++------+---------------------+
+| 2 | 2008-12-31 18:00:23 |
++------+---------------------+
+1 row in set (0.02 sec)
+</programlisting>
+
</section>
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r12984 - in trunk: . refman-5.0 | paul.dubois | 23 Dec |
