Bug in the _as_datetime() function

[GoogleCodeExporter]

                       project_name: common_schema
                            version: 2.2
                           revision: 523
                       install_time: 2013-12-18 18:53:25
                    install_success: 1
          base_components_installed: 1
 innodb_plugin_components_installed: 1
percona_server_components_installed: 1
              install_mysql_version: 5.5.25a-27.1-log
                   install_sql_mode: NO_AUTO_VALUE_ON_ZERO

The _as_datetime() function misbehaves with timestamps the look look like real 
dates.

For example for the UNIX_TIMESTAMP('2014-05-28') = 1401220800. And 
_as_datetime('1401220800') = '2014-01-22 08:00:00'.

This causes problems with common_schema.sql_range_partitions view when one has 
a table PARTITION BY RANGE (UNIX_TIMESTAMP(date_column)).

Other "special" dates are
2014-06-08 00:00:00
2014-06-19 00:00:00
2014-06-30 00:00:00
2014-07-14 00:00:00
2014-07-25 00:00:00
2014-09-08 00:00:00
2014-09-19 00:00:00
2014-09-30 00:00:00
2014-10-03 00:00:00
2017-07-29 00:00:00
2017-09-12 00:00:00
2017-09-23 00:00:00
2017-10-04 00:00:00
2017-10-15 00:00:00
2017-10-18 00:00:00
2017-10-29 00:00:00
2017-11-09 00:00:00
2017-11-20 00:00:00
2017-12-01 00:00:00
2020-09-27 00:00:00
2020-10-08 00:00:00
2020-10-19 00:00:00
2020-10-22 00:00:00
2020-11-02 00:00:00
2020-11-13 00:00:00
2020-11-24 00:00:00
2020-12-05 00:00:00
2020-12-30 00:00:00
2023-11-29 00:00:00
2023-12-10 00:00:00
2024-01-24 00:00:00
2024-02-18 00:00:00
2024-02-29 00:00:00
2024-03-11 00:00:00
2024-03-22 00:00:00
2024-04-05 00:00:00
2027-01-28 00:00:00
2027-02-08 00:00:00
2027-02-22 00:00:00
2027-03-05 00:00:00
2027-03-16 00:00:00
2027-03-27 00:00:00
2027-04-07 00:00:00
2027-04-10 00:00:00
2027-04-21 00:00:00
2027-05-02 00:00:00
2027-05-13 00:00:00
2027-06-07 00:00:00
2030-03-31 00:00:00
2030-04-11 00:00:00
2030-04-22 00:00:00
2030-04-25 00:00:00
2030-05-06 00:00:00
2030-05-17 00:00:00
2030-07-01 00:00:00
2030-07-12 00:00:00
2030-07-26 00:00:00
2030-08-06 00:00:00
2033-07-05 00:00:00
2033-07-16 00:00:00
2033-07-27 00:00:00
2033-07-30 00:00:00
2033-08-10 00:00:00
2033-08-21 00:00:00
2033-09-01 00:00:00
2033-09-12 00:00:00
2033-09-23 00:00:00
2033-09-26 00:00:00
2033-10-07 00:00:00
2036-07-31 00:00:00
2036-08-11 00:00:00
2036-08-14 00:00:00
2036-08-25 00:00:00
2036-09-05 00:00:00
2036-09-16 00:00:00
2036-09-27 00:00:00
2036-10-11 00:00:00
2036-10-22 00:00:00
2036-12-06 00:00:00

Original issue reported on code.google.com by slkole...@gmail.com on 27 May 2014 at 10:31

[GoogleCodeExporter]

Confirmed. An immediate solution should be to check string length in 
_as_datetime and return NULL if it's 10. This actually introduces an implicit 
bug in that we cannot parse 10 characters long dates, but these are anyhow 
unorthodox representations.

Original comment by shlomi.n...@gmail.com on 27 May 2014 at 11:42

• Changed state: Accepted

[GoogleCodeExporter]

This issue was closed by revision r554.

Original comment by shlomi.n...@gmail.com on 27 May 2014 at 12:49

• Changed state: Fixed

[GoogleCodeExporter]

10 digit timestamps are not considered to be datetime objects.

Original comment by shlomi.n...@gmail.com on 27 May 2014 at 12:50

[GoogleCodeExporter]

Thanks!

Original comment by slkole...@gmail.com on 27 May 2014 at 12:54