Is that a problem deserialize datetime/time?

[justin177]

In those processes, they all use this method: com.github.shyiko.mysql.binlog.event.deserialization.AbstractRowsEventDataDeserializer#asUnixTime(int year, int month, int day, int hour, int minute, int second, int millis) to return a timestamp, and it just simply to invoke this one: com.github.shyiko.mysql.binlog.event.deserialization.AbstractRowsEventDataDeserializer.UnixTime#from(int year, int month, int day, int hour, int minute, int second, int millis) You can see the method UnixTime#from will return a UTC-based timestamp. Now suppose your mysql server's time_zone is '+8:00'. You have a field with type datetime named 'modify_time' with value '2017-03-21 03:02:00', and the BinaryLogClient running in the server will receive an event with this value. You may have realized the problem:all time value are treated as UTC, when you use the time in the client, it will defer to that in mysql server depends on the timezone. In this case, you will get '2017-03-21 11:02:00'.

So, is it a problem or is there a solution?

[shyiko]

Hi.

AFAIR "time" is converted to UTC for storage and then converted back to the current timezone for retrieval (this latter step does not happen when reading the binary log though). In other words, DATE, DATETIME, and TIMESTAMP should be returned in UTC (any timezone conversion will have to be done outside of mysql-binlog-connector-java). I haven't done much testing when it comes down to TZs (as generally accepted practice to keep timezone fixed to GMT across all the servers alleviates any TZ-related problems) and so please let me know if the behavior described above is not what you actually observe.

Thank you.

[justin177]

OK, I know you point, this is actually not a middleware should be concerned about.