Bug #73541 | Export Data - Date type not auto-detected when locale is different | ||
---|---|---|---|
Submitted: | 11 Aug 2014 23:21 | Modified: | 9 Oct 2014 23:27 |
Reporter: | Javier Treviño | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL for Windows: MySQL for Excel | Severity: | S3 (Non-critical) |
Version: | 1.2.0 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[11 Aug 2014 23:21]
Javier Treviño
[25 Aug 2014 21:05]
Javier Treviño
Posted by developer: Changed the way null and zero dates are handled, in previous versions MySQL zero dates ("0000-00-00 00:00:00") were imported in Excel as the minimum valid date allowed by .NET (DateTime.MinValue). Excel ListObjects bound to DataTables containing DateTime.MinValue are automatically converted into a text representation so the cell's value is no longer recognized as a date (possible VSTO bug). Now zero dates are always treated as null, so even typing a 0 in a date column translates to a null date. Logic that recognizes date values string or boxed objects was rewritten from scratch to fix also bugs with dates in a locale different than US English.
[9 Oct 2014 23:27]
Philip Olson
Posted by developer: Fixed as of the upcoming MySQL for Excel 1.3.3 release, and here's the changelog entry: Changed the way NULL and zero dates are handled. Previously, MySQL zero dates ("0000-00-00 00:00:00") were imported into Excel as the minimum valid date allowed by .NET (DateTime.MinValue), which was then converted into a text representation where the cell's value was no longer recognized as a date. Now, zero dates are always treated as NULL. Thank you for the bug report.