Bug #32390 Character sets: casting utf32 to/from date doesn't work

Submitted: 14 Nov 2007 19:47 Modified: 28 Jul 2008 20:38
Reporter: Peter Gulutzan Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Charsets Severity:S3 (Non-critical)
Version:6.0.5-alpha-debug OS:Linux (SUSE 10 64-bit)
Assigned to: Alexander Barkov CPU Architecture:Any

[14 Nov 2007 19:47] Peter Gulutzan
Description:
I'm using the mysql-5.2-rpl team tree.

I create a table with a utf32 column.
I try to insert a DATE, expecting date-to-char conversion. That fails.
I try to use CAST for a char-to-date conversion. That fails.

With ucs2: the insert would work, the CAST would not, that's known.

How to repeat:
create table n (s1 varchar(10) character set utf32);
insert into n values (current_date);
show warnings;
delete from n;
insert into n values ('0001-01-01');
select cast(s1 as date) from n;
show warnings;

Example:

mysql> create table n (s1 varchar(10) character set utf32);
Query OK, 0 rows affected (0.00 sec)

mysql> insert into n values (current_date);
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+--------------------------------------------------------------+
| Level   | Code | Message                                                      |
+---------+------+--------------------------------------------------------------+
| Warning | 1366 | Incorrect string value: '07-11-...' for column 's1' at row 1 |
+---------+------+--------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> delete from n;
Query OK, 1 row affected (0.00 sec)

mysql> insert into n values ('0001-01-01');
Query OK, 1 row affected (0.00 sec)

mysql> select cast(s1 as date) from n;
+------------------+
| cast(s1 as date) |
+------------------+
| NULL             |
+------------------+
1 row in set, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+------------------------------+
| Level   | Code | Message                      |
+---------+------+------------------------------+
| Warning | 1292 | Incorrect datetime value: '' |
+---------+------+------------------------------+
1 row in set (0.00 sec)
[15 Nov 2007 2:16] MySQL Verification Team
Thank you for the bug report. Verified as described.
[18 Jul 2008 6:04] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/49992

2723 Alexander Barkov	2008-07-18
      Bug#32390 Character sets: casting utf32 to/from date doesn't work
      Problem: insertion of CURRENT_TIME, CURRENT_DATE and CURRENT_TIMESTAMP
      into a varchar column didn't work for non-ASCII character sets
      like ucs2, utf16 and utf32. That happened because character set
      of the inserted value was specified as my_charset_bin.
      Fix:
      - for tricky character set we specify my_charset_latin1,
      which forces character set conversion and thus make insertion correct.
      - for non-tricky character set we still use my_charset_bin to
      avoid unnesessary conversion.
      
      
      - mysql-test/include/ctype_datetime.inc:
      A new shared test include file
      
      
      - mysql-test/r/ctype_ucs.result
      - mysql-test/r/ctype_utf16.result
      - mysql-test/r/ctype_utf32.result
      - mysql-test/t/ctype_ucs.test
      - mysql-test/t/ctype_utf16.test
      - mysql-test/t/ctype_utf32.test:
      Adding tests
      
      - sql/field.cc
      The fix itself: pass proper character set value to store().
[22 Jul 2008 9:32] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/50168

2732 Alexander Barkov	2008-07-22
      Bug#32390 Character sets: casting utf32 to/from date doesn't work
      Problem: insertion of CURRENT_TIME, CURRENT_DATE and CURRENT_TIMESTAMP
      into a varchar column didn't work for non-ASCII character sets
      like ucs2, utf16 and utf32. That happened because character set
      of the inserted value was specified as my_charset_bin.
      Fix:
      - for tricky character set we specify my_charset_latin1,
      which forces character set conversion and thus make insertion correct.
      - for non-tricky character set we still use my_charset_bin to
      avoid unnesessary conversion.
      
      
      - mysql-test/include/ctype_datetime.inc:
      A new shared test include file
      
      
      - mysql-test/r/ctype_ucs.result
      - mysql-test/r/ctype_utf16.result
      - mysql-test/r/ctype_utf32.result
      - mysql-test/t/ctype_ucs.test
      - mysql-test/t/ctype_utf16.test
      - mysql-test/t/ctype_utf32.test:
      Adding tests
      
      - sql/field.cc
      The fix itself: pass proper character set value to store().
[22 Jul 2008 9:34] Alexander Barkov
Pushed into 6.0.7-bugteam
[28 Jul 2008 14:45] Bugs System
Pushed into 6.0.7-alpha  (revid:alik@mysql.com-20080725172155-fnc73o50e4tgl23k) (version source revid:alik@mysql.com-20080725172155-fnc73o50e4tgl23k) (pib:3)
[28 Jul 2008 20:38] Paul DuBois
Noted in 6.0.7 changelog.
[13 Sep 2008 22:01] Bugs System
Pushed into 6.0.6-alpha  (revid:bar@mysql.com-20080722092546-rb02kr9f7hs8y8g9) (version source revid:hakan@mysql.com-20080716105246-eg0utbybp122n2w9) (pib:3)

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.061 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.