Connector/J version 8.0.23 came out with several bug fixes related to date-time types support. They provide more flexibility for configuring time zone handling and allow migration from Connector/J 5.1 with much less effort.

Problems with migration from Connector/J 5.1 to Connector/J 8.0 were caused by the early decision that Connector/J 8.0 should always try to preserve an instant point on the time-line while Connector/J 5.1 does it optionally and, by default, preserves the original visual representation.

For example, the following code will store different results with Connector/J 5.1 and Connector/J 8.0 in case the client and server time zones are different:

Statement st = conn.createStatement();
st.executeUpdate("CREATE TABLE t1 (ts TIMESTAMP)");

PreparedStatement ps = conn.prepareStatement("INSERT INTO t1 VALUES (?)");
ps.setTimestamp(1, Timestamp.valueOf("2020-01-01 12:00:00"));
ps.executeUpdate();

If the client …

March is not only the month when a pandemic closed all borders and people had to stay home on the quarantine; it’s also the month when daylight saving time change happens. For some regions, this is not only a time change but also a switch to a different timezone. For example, New York uses EST during winter and EDT during summer. If you use the system timezone and do not restart the MySQL server or a PXC node after the switch, you may notice that the change was not implemented.

You may end up with a situation where some of your cluster nodes still use the time zone before the switch (e.g. EST) and others use the timezone after the change (e.g. EDT).

$ date
Sun Mar  8 03:03:28 EDT 2020

$ ./bin/mysql  -h127.0.0.1 -P3373 -uroot test
...
EDT node> show variables like '%zone%'; …

Notes/errata/updates for Chapter 6:
See the official book errata at http://tahaghoghi.com/LearningMySQL/errata.php – Chapter 6 includes pages 179 – 222.

Other notes:
At the end of the “Creating Tables” section (p.183-4), it says “We like using the underscore character to separate words, but that’s just a matter of style and taste; you could use underscores or dashes, or omit the word-separating formatting altogether.” While this is true, beware of using a dash, because MySQL will try to interpret “two-words”, thinking – is a minus sign. I recommend avoiding dashes for this reason (even though the book does this on page 215).

At the end of the “Collation and Character Sets” section (p.186), it says “When you’re creating a database, you can set the default character set and sort order for the database and its …

Introduction Dealing with time zones is always challenging. As a rule of thumb, it’s much easier if all date/time values are stored in the UTC format, and, if necessary, dealing with time zone conversations in the UI only. This article is going to demonstrate how you can accomplish this task with JDBC and the awesome … Continue reading How to store date, time, and timestamps in UTC time zone with JDBC and Hibernate →

Twice last week, a developer wanted to convert the existing datetime values in a database to UTC. The datetime values were the default for the server, which was the US/Pacific time zone, which is subject to Daylight Saving Time changes. Both developers for both applications wanted to convert all the times to UTC, so there would not be any changes due to Daylight Saving Time, and asked me for an easy query to know which times should be changed by adding 7 hours and which times should have 8 hours added to them.

The good news is that MySQL has some built-in functionality to make this easier. You may know about the CONVERT_TZ() function in MySQL, and that you can use it in a query to convert times like this:

mysql> SELECT CONVERT_TZ(NOW(),'-8:00','-0:00');
+-----------------------------------+
| …

How old is your timezone info?
As the timezone database gets updated frequently, it's important to update the internal timezone database in MySQL. This is needed for the CONVERT_TZ() function for work properly.

It's not easy to determine if the data in mysql is older than the data from the tzdata database. It get's a bit better if you use this hack before importing the zone database:
ALTER TABLE mysql.time_zone_transition ADD COLUMN `Last_Update` TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;I've created Bug #60675 to get the system database updated.

Which database serves still need timezone info?
Use …

Background Knowledge

I’m trying to determine the difference in minutes between two timestamps. I’m using Pear::Date to do this. The issue comes into play when I noticed that the wrong timezone was being used by Pear::Date, UTC. If I do not use Pear::Date the timezone is set correctly.

I have tried using date_default_timezone_set() and it does set the timezone back, however I feel this shouldn’t be necessary as the default timezone should be used. I have been using date_default_timezone_get() to determine what timezone is being used.

It’s my understanding that Pear::Date uses UTC when it is unable to determine the default timezone. As far as I know I have the default timezone set correctly and with a …

While playing around with the great MySQL Activity Reporter , I ran into the following error.

[client 192.168.254.72] PHP Fatal error: strftime() [function.strftime]: Timezone database is corrupt - this should *never* happen! in /var/lib/mysqlard/mysqlar.php on line 62

Now the error is clear .. the Timezone database is corrupt and I`m the one to blame for .. this was on a pretty stripped down Centos that lives in UTC. So there wasn't a real Timezone database.

Obviously a quick apt-get install tzdata solved the problem, but once again the lesson is.. don't strip too much .. you'll eventually endup needing those 3 Kb of free space you gained anyhow.

While playing around with the great MySQL Activity Reporter , I ran into the following error.

[client 192.168.254.72] PHP Fatal error: strftime() [function.strftime]: Timezone database is corrupt - this should *never* happen! in /var/lib/mysqlard/mysqlar.php on line 62

Now the error is clear .. the Timezone database is corrupt and I`m the one to blame for .. this was on a pretty stripped down Centos that lives in UTC. So there wasn't a real Timezone database.

Obviously a quick apt-get install tzdata solved the problem, but once again the lesson is.. don't strip too much .. you'll eventually endup needing those 3 Kb of free space you gained anyhow.