| Bug #2336 | Different number of warnings when inserting bad datetime as string or as number | ||
|---|---|---|---|
| Submitted: | 9 Jan 2004 9:12 | Modified: | 19 Jun 2004 11:10 |
| Reporter: | Dmitry Lenev | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server | Severity: | S3 (Non-critical) |
| Version: | bk-4.1 | OS: | Any (all) |
| Assigned to: | Dmitry Lenev | CPU Architecture: | Any |
[9 Jan 2004 12:10]
Dmitry Lenev
One more inconsistency in TIMESTAMP handling: mysql> insert into testts values ( '2003-01-00 03:00:01'); Query OK, 1 row affected (0.01 sec) mysql> insert into testts values (20030100030001); Query OK, 1 row affected (0.00 sec) mysql> select * from testts; +---------------------+ | ts | +---------------------+ | 0000-00-00 00:00:00 | | 2003-01-01 03:00:01 | +---------------------+ Note: such datetime values is ok for DATETIME type...
[19 Jun 2004 11:10]
Dmitry Lenev
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.
If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information
about accessing the source trees is available at
http://www.mysql.com/doc/en/Installing_source_tree.html
Additional info:
ChangeSet 1.1931.1.1 2004/06/18 10:11:31 dlenev@brandersnatch.localdomain
WL#1264 "Per-thread time zone support infrastructure".
...
Fixed problems described in Bug #2336 (Different number of warnings
when inserting bad datetime as string or as number).
[25 May 2012 9:59]
Mannoj S
Hi a qq, is this is str_to_timestamp is available ? If so which release it has been added.
Description: MySQL reports warning when bad DATETIME value is inserted as number literal and doesn't do this if bad DATETIME value is inserted as string literal. The same is true for TIMESTAMP columns. Note that warnings being generated for TIMESTAMP column and DATETIME column differ without any obvious reason. How to repeat: mysql> create table testdt (dt datetime); Query OK, 0 rows affected (0.02 sec) mysql> insert into testdt values (20030101010160); Query OK, 1 row affected, 1 warning (0.01 sec) mysql> show warnings; +---------+------+-----------------------------------------+ | Level | Code | Message | +---------+------+-----------------------------------------+ | Warning | 1264 | Data truncated for column 'dt' at row 1 | +---------+------+-----------------------------------------+ 1 row in set (0.00 sec) mysql> insert into testdt values ("20030101010160"); Query OK, 1 row affected (0.01 sec) mysql> create table testts (ts timestamp); Query OK, 0 rows affected (0.02 sec) mysql> insert into testts values (20030101010160); Query OK, 1 row affected, 1 warning (0.02 sec) mysql> show warnings; +---------+------+-------------------------------------------------------+ | Level | Code | Message | +---------+------+-------------------------------------------------------+ | Warning | 1263 | Data truncated, out of range for column 'ts' at row 1 | +---------+------+-------------------------------------------------------+ 1 row in set (0.00 sec) mysql> insert into testdt values ("20030101010160"); Query OK, 1 row affected (0.00 sec) Suggested fix: Fix THD::cuted_fields handling in str_to_TIME() and str_to_datetime() and str_to_timestamp() functions.