"timestamp is timezone-sensitive"?

[wushujames]

You say in the README "timestamp is timezone-sensitive".

What do you mean, exactly? The bytes in the binary log represent time since the epoch in UTC, right? When they are loaded into a java.sql.Date() on a machine running in the Pacific timezone (GMT-8)... what happens?

[shyiko]

Hi.

The bytes in the binary log represent time since the epoch in UTC, right?

Correct.

What I meant was - if you save 1989-03-18 01:02:03 from GMT and read from GMT-08:00 you'll get 1989-03-17 17:02:03. More on that here (fifth paragraph). Deserialization itself - AbstractRowsEventDataDeserializer.java#L211.

[wushujames]

Okay, I read paragraph 5. That makes sense, but it seems to only apply for mysql client connections for SELECTs and stuff. I don't think it would apply to the binary logs. In that respect, is there a reason you specified it in the Implementation Notes? How does it apply for this project?

I'm using your project to take the binlog events and encode them to json, so I wanted to see if there's anything I need to be careful about.

I'm using Jackson for the json encoding, and the page http://wiki.fasterxml.com/JacksonFAQDateHandling says
"Notes on java.sql.Date (aka "Please do NOT use java.sql.Date, ever!")"
so I'm trying to understand why and what I need to do. Still trying to learn about Java and Dates and timezones.

[shyiko]

As long as you keep timezone fixed across the servers (hopefully in UTC) you don't have to worry about anything. It just works. But, as soon as you deviate, you'll have to compensate (e.g. if you want serialize java.sql.* in local timezone you'll need to convert them with an appropriate offset before they can be passed to the Jackson). Again, the rule of thumb is to be consistent. The sole reason I mentioned timezones in the implementation notes was to make sure people think about it beforehand, but... I see now that it can be a bit misleading. I'll remove it.

Thank you.