This blog post has moved. Please find it at:
http://www.mpopp.net/2006/01/mysqldumps-tz-utc-trap/.
Subscribe to:
Post Comments (Atom)
skip to main |
skip to sidebar
This is all about db4free.net and the database systems that it offers. The main focus are practical examples of the new features of MySQL 5 and 6 that should show you how to use them for your advantage in your daily life ;-).
About Me
Links
Blog Archive
-
▼
2006
(124)
-
▼
January
(25)
- No MySQL forum category for migration from Postgre...
- Book by Karl Fogel - Producing Open Source Software
- How to deal with repeating date intervals?
- Joomla still doesn't work with SQL mode enabled
- The 'to enum or not to enum' question
- Emulating check constraints with views?
- A little look into the (near) future
- Emulating check constraints
- Is this a bug?
- Creating log tables with triggers
- XAMPP
- Ideas for db4free.net?
- Calculating time spans and ... a bug?
- Everybody can post comments again ;-) ...
- MySQL 5.0 Beta Certification Exams available
- db4free.net CleanUp process (2)
- mysqldump and mysqlcheck now work perfectly
- What's wrong with MySQL QueryBrowser?
- MySQL 5.1 evolves
- mysqldump's tz-utc trap
- A little join problem
- Index information from information_schema
- PostgreSQL's MySQL compatibility functions
- Hail to GROUP_CONCAT!
- Happy and successful new year!
-
▼
January
(25)
2 comments:
I don't think that it's a bug, I can dump a table containing date/time information and re-import it and get the same results, at least on the same MySQL 5.0 server from where the dump file results. However, I created yesterday's dump file from a MySQL 4.0 server, so maybe there's some incompatibility. But with disabling tz-utc it was easy to work around this problem.
Thank you very much for clarifying this. I ran into the problem when restoring parts of a single table due to a user accidentally deleting... in case partial restores are needed, no timezone conversion makes life far more easier.
Post a Comment