tomato times in local time

[cori]

Looks like the timestamps for tomatoes are behind by an hour in my tz. Could be a summer time thing...

[potomak]

this is a js setting cookie with your browser timezone: https://github.com/potomak/tomatoes/blob/develop/public/javascripts/time_zone.js

and this is the filter using cookie value to set the correct timezone: https://github.com/potomak/tomatoes/blob/develop/app/controllers/application_controller.rb#L13

where do you think I'm wrong?
can you add a test case for this bug?

[cori]

I do think there's something wrong in your tz offset calculation - I am in US Central, and we are currently observing DST so should be at UTC-5, but the cookie that's being set makes my timezone UTC-6, which matches what I'm seeing in the timestamps

[cori]

indeed - since you're using the max of january's tz offset and july's offset you're always goign to get 360 for my timezone (at least as I read things). Any reason why you're not just using new Date().getTimezoneOffset()?

I'll stick that into my fork tonight and see if it works....

[potomak]

You can't use getTimezoneOffset because of DST.

Example 1:
I live in a place near Venice, Italy, time zone: CEST (+1, now +2 with DST).
If I run new Date().getTimezoneOffset() now the result is -120 (-60 time zone + -60 DST).
Saving this value in the cookie will make ruby select a wrong time zone: EEST (+2) instead of CEST (+1).

This happens because ActiveSupport::TimeZone ignores DST storing time zones indexed by standard time zone offset.

Example 2:
You live in Wisconsin, USA (got this info from your Twitter account), time zone: CST (-6, now -5 with DST).
If you run new Date().getTimezoneOffset() now the result should be 300 (360 time zone + -60 DST).
Saving this value in the cookie will make ruby select a wrong time zone: COT (-5) instead of CST (-6).

What do you think about?

[cori]

OK, I see the issue. That said, is having ruby select the right timezone important for any reason other than displaying the local times? In other words, does it matter that ruby is selecting COT instead of CST for me as long as the times displayed are correct?

From what I can tell (and I'm only starting to learn ruby) you're using it primarily to set created time in the db. I created a tomato in my db last night which has the created at of "created_at" : "Tue Sep 20 2011 22:20:32 GMT-0500 (CST)", which is correct right now - I am at GMT-0500.

What am I missing?

[potomak]

Mongoid stores dates in production using UTC.

In Mongoid configuration I set use_activesupport_time_zone to true (see https://github.com/potomak/tomatoes/blob/develop/config/mongoid.yml#L14) to tell Mongoid to convert dates using current rails time zone.

See also https://github.com/mongoid/mongoid/issues/878

[cori]

I guess I'm just dense because I'm still not seeing the problem with using the timezone determined by getTimezoneOffset. The dates are getting converted to the dictated offset on the way into the db, right? So a tomato I created yesterday at 12:00-12:25 my time will still show as 12:00-12:25 GMT-0500 after the DST switch, right?

It seems like all of the timezone manipulations are just to get the right offset for grouping of tomatoes into days and to render the local time on the page. If that's the case what's important is really the offset and not the timezone per se, so it doesn't really matter what named timezone I am in. Perhaps there's something in the Freckle integration that makes the actual timezone important? If there's some other aspect of the functionality of Tomatoes that makes the named TZ important I would like to know; I don't understand how its's important, but would love to learn more about it....

All of which said - the hour difference isn't really that big of a deal for me - I'm not using the times for anything of real import, so if there's a side effect that I'm not considering then it's not worth a lot of effort, at least not for me.

[potomak]

You're not right, they're not converted into the db, they're converted only when they become ruby objects (mongoid models). Into the DB you should put only UTC dates!

Cori, we need a test case, or real examples, otherwise we're talking about nothing.

Yes, timezone manipulations are just to get the right offsets in views, they're not concerning the Freckle connection (also because Freckle API and support suck) anyway I'd really like to resolve this issue.

[cori]

Not sure exactly how exactly to define the test case, because I can't force the correct behavior.

The timezone cookie setter will always set to 360 for my timezone - the max of Jan 1's offset (-360) and July 1's offset (-300). That's correct during CST (US Central Standard Time) but incorrect during CDT (US Central Daylight Time). My supposition is that when my clock flips to CST in November Tomatoes will show the correct times, but for right now they are 1 hour behind.

I saw your tweet, perhaps another US user will come forward....

[potomak]

Ok! I've finally got it!

Some notes to explain the problem:

1. it's right to get always the maximum time zone offset from javascript
2. ActiveSupport::TimeZone[] (http://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-c-5B-5D) returns the first time zone with that offset

Your current time zone offset is 300 (using DST), but the standard offset is 360. The algorithm chooses the maximum between 300 and 360, so it chooses 360.

The problem is ActiveSupport::TimeZone[-360.minutes].dst? returns false, but why?
Because the first time zone selected with that offset is not yours but Guatemala's one which doesn't observe DST.
You can check this behavior by calling ActiveSupport::TimeZone[-360.minutes].tzinfo, it should return #<TZInfo::TimezoneProxy: America/Guatemala>.

The only solution it to ask people to set their time zone manually.

[cori]

uff da.

I see what you're saying about the max and after reading around a little I see what you're doing with the timezone getter - essentially you want the standard offset, which is the greater of standard time or dst (exemplified by the client offset on jan 1 vs jul 1). Then you're using ActiveSupport::TimeZone to figure out if the user is in DST or not.

Thanks for clarifying. Always good to learn something new....

[guerrerocarlos]

I dont know how it works jet, (I'm just about to study the app code) but reading this thread I have a question:

I understand that you try to get the right timezone from the user, to use it when saving the tomato inside the application and make it have the right time, but why dont you just take the actual hour from the user browser with javascript, and save the tomato with that information instead of calculating it with hour the server hour and the timezone calculation ?

[potomak]

Just think about software you're using right now: why does Twitter ask you for your timezone?
One reason I'm doing it the way it is is because I think your solution could lead to worst data manipulation processes, but I think there's a really clever answer to this question I still don't know.
In my opinion the only reasonable way to achieve this challenge is to ask users' timezone.

[guerrerocarlos]

Why would it lead to worst data manipulation processes ?

You can clearly get the exact hour from the user browser and use it as the tomato datetime, right ?

[guerrerocarlos]

Maybe using the IP's timezone? :)

try:

http://api.ipinfodb.com/v3/ip-city/?key={{API_KEY}}&ip=190.188.221.244&timezone=true

returns:

OK;;190.188.221.244;AR;ARGENTINA;BUENOS AIRES;LA PLATA;-;-34.931;-57.949;-03:00

Source: http://stackoverflow.com/questions/2543018/what-python-libraries-can-tell-me-approximate-location-and-timezone-given-an-ip