Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Provide a timezone for serializing timestamps #191

Closed
wants to merge 1 commit into
from

Conversation

5 participants
Contributor

eric commented Aug 5, 2013

Adds a way to specify the timezone that dates and times are serialized in.

This is a proposed fix for #190.

Provide a timezone for serializing timestamps
Adds a way to specify the timezone that dates and times are serialized in.
Member

roanta commented Aug 5, 2013

I'm not sure this is the direction I would go with this. If you are convinced that connection level granularity for timezones is what we want, I think a better approach would be to auto-negotiate the timezone when a connection is established.

Also, I don't want to associate the Client with one connection, even though it is the case now, this is something that will likely change. We actually have a PR internally that changes the Client (and would be incompatible with this change). Do you mind if we revisit this later?

Contributor

eric commented Aug 5, 2013

The auto-negotiation is interesting... I'll look into that.

I would argue that the timezone is related to the "connection specification", so I still think the Client is a reasonable place to specify the timezone to use for the data type.

Contributor

eric commented Aug 5, 2013

I've temporarily resorted to using this hack to get the datetime written in UTC: CONVERT_TZ(FROM_UNIXTIME(?), @@session.time_zone, '+0:00')

Contributor

mosesn commented Jul 2, 2014

We ended up solving a similar problem recently. We solved it with this commit. @eric do you think that will solve your problem?

Contributor

mosesn commented Aug 6, 2014

@eric haven't heard from you lately, so I'm going to close this PR for now. If you run into more problems, please let us know and we can reopen it.

@mosesn mosesn closed this Aug 6, 2014

Contributor

eric commented Aug 6, 2014

Could you give me more detail as to how that solves the problem?

Part of the issue is that a datetime in MySQL has no attached timezone, so without knowing the timezone the client that inserted the record intended to use, or without knowing what the timezone of the server is, how can we know what to use here?

@mosesn mosesn reopened this Aug 6, 2014

Contributor

mosesn commented Aug 6, 2014

Here we're just forcing everyone to UTC, so it doesn't matter what the client's original timezone was. I don't think I understand your question.

Contributor

eric commented Aug 6, 2014

Well, in ActiveRecord (in ruby), for instance, you can specify what timezone you would like all of your dates to be specified in.

Now, it is obviously A Good Idea to always pick UTC, but it certainly isn't a requirement. So, if someone had not picked UTC, this wouldn't be giving them the right result.

So it seems to me that there would need to be a setting on either the connection or the statement that said, "This is the timezone I want you to think of the dates and times as being in".

Contributor

mosesn commented Aug 6, 2014

Oh, it occurs to me that what I linked to wasn't the entire thing. The first commit was here. I'll try to get the person worked on it in here to talk with you.

Contributor

jcrossley commented Aug 6, 2014

Hi Eric, I'm just wrapping up a pull request related to this issue. DATETIME types are interpreted as UTC in the TimestampValue extractor. If you'd like to have them treated as another timezone, you could write your own extractor for a RawValue. There isn't currently a way to specify a different timezone.

Contributor

jcrossley commented Aug 6, 2014

I looked over your pull request, Eric. Perhaps you could add a test to verify the desired behaviour?

Contributor

eric commented Mar 23, 2015

Sorry, I ended up not having time to circle back on this and have moved to just using JDBC.

Contributor

mosesn commented Mar 24, 2015

Bummer, thanks for the update.

@luciferous luciferous closed this Jul 14, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment