Time zone trouble with time_ago_in_words

[redbar0n]

There seems to be a problem with how dotiw overwrites the time_ago_in_words method with respect to handling of time zones.

Maybe because it is using Time.now instead of Time.zone.now ?

With dotiw:

irb(main):010:0> Time.now
=> 2015-09-29 11:57:55 +0000
irb(main):011:0> Time.zone.now
=> Tue, 29 Sep 2015 13:57:59 CEST +02:00
irb(main):016:0> helper.time_ago_in_words(3.minutes.from_now)
=> "1 hour and 2 minutes"

irb(main):018:0> helper.time_ago_in_words(Time.now+3.minutes)
=> "2 minutes"
irb(main):019:0> helper.time_ago_in_words(Time.zone.now+3.minutes)
=> "1 hour and 2 minutes"

As you can see, there comes an extra hour there. I don't know why.

In another app, without dotiw:

2.1.1 :002 > helper.time_ago_in_words(3.minutes.from_now)
 => "3 minutes" 
2.1.1 :003 > helper.time_ago_in_words(Time.now+3.minutes)
 => "3 minutes" 
2.1.1 :004 > helper.time_ago_in_words(Time.zone.now+3.minutes)
 => "3 minutes" 

[redbar0n]

The 1 hour difference seems to come from:

irb(main):007:0> helper.distance_of_time_in_words(Time.now, Time.zone.now)
=> "1 hour"

Which is weird in itself, because the time zone is actually 2 hours in front of GMT:

irb(main):008:0> Time.now
=> 2015-09-29 12:23:23 +0000
irb(main):009:0> Time.zone.now
=> Tue, 29 Sep 2015 14:23:26 CEST +02:00

Does dotiw do something especially, when accounting for summer time (like CEST)?

[radar]

No, dotiw does nothing special when accounting for any particular timezone.

[radar]

It's possible this bug is caused by using Time.now. Please submit a PR that uses Time.zone.now instead.

[arjun810]

The Time.zone.now fix helped, but there's still a bug here if someone passes both times in:

[28] » from_time = Time.zone.now
=> Thu, 17 Mar 2016 02:09:31 PDT -07:00
[29] » p a.h.distance_of_time_in_words(from_time+1.hour, Time.now, {})
"1 hour and 59 minutes"
=> "1 hour and 59 minutes"

I think the cause is here:
https://github.com/radar/dotiw/blob/master/lib/dotiw/time_hash.rb#L21
(lines 21 and 22)

Are these necessary? It seems that subtracting times already handles dst properly, and these are actually causing bugs.

[redbar0n]

I agree with @arjun810's analysis.

I think the problem lies in that 3.minutes.from_now actually uses Time.zone.now, which already handles DST (like CEST), and so those lines in dotiw's TimeHash class that tries to handle DST too will cause those bugs.

I think it is better to leave it to Ruby/Rails to handle time zones and DST.

http://apidock.com/rails/ActiveSupport/Duration/from_now
is alias for http://apidock.com/rails/ActiveSupport/Duration/since
which uses http://apidock.com/rails/Time/current/class
which "Returns Time.zone.now when Time.zone or config.time_zone are set, otherwise just returns Time.now."

[lauranjansen]

I will submit a PR to remove the weird time zone adjustment lines, which shouldn't be needed anymore.

[alexmarles]

I recently ran into this problem using the last version of the gem and I see the last response to this thread is from over a month ago. Any ideas on how to solve it or any workaround/patch to apply?

[theoreichel]

I can easily reproduce the issue with the following example:

> include ActionView::Helpers::DateHelper
> Time.zone = "CET"
> distance_of_time_in_words(Time.now.utc, 1.hour.ago)
=> "less than 1 second"

and of course this (almost) works:

> distance_of_time_in_words(Time.now.utc, 1.hour.ago.utc)
=> "59 minutes"

So forcing time to UTC seams to solve the issue, just like if comparison were done without handling timezone.

[lauranjansen]

I tried just removing the time zone adjustments to see if using Time.zone.now, but for me that didn't solve the issue. I will try to add the provided cases to the tests and will play around with it some more when I have time.

[ivanovv]

Just my 2 cents here:

we have an issue with this gem and clockwork_web gem, all timestamps are off by an hour

irb(main):085:0> helper.distance_of_time_in_words_hash(Time.now, ClockworkWeb.last_heartbeat)
=> {:seconds=>9}
irb(main):086:0> helper.distance_of_time_in_words_hash(Time.current, ClockworkWeb.last_heartbeat)
=> {:hours=>1, :seconds=>9}

I think when we are speaking about time difference, we really don't care about th timezone, because essentially things happen at one specific point in time, timezones just define the way we show those points (timestamps), but for two specific moments in time the distance between them is always the same and doesn't depend on timezone

So I do think that converting to to_i and using the diff between two numbers is the way to go here.

[shaicoleman]

I think it's because it calcluates differences in times and not in dates.

The specs are failing when run in a different timezone, despite the timezone set to UTC, e.g.

$ TZ='Europe/Dublin' bundle exec rspec
rspec './spec/lib/dotiw_spec.rb[1:1:9]' # A better distance_of_time_in_words #distance_of_time 14515200 == 5 months, 2 weeks, and 1 day
rspec './spec/lib/dotiw_spec.rb[1:4:10]' # A better distance_of_time_in_words #distance_of_time_in_words should be 11 months and 2 days
rspec './spec/lib/dotiw_spec.rb[1:4:11]' # A better distance_of_time_in_words #distance_of_time_in_words should be 11 months, 2 days, and 1 minute
rspec './spec/lib/dotiw_spec.rb[1:4:12]' # A better distance_of_time_in_words #distance_of_time_in_words should be 1 year, 4 weeks, and 1 day
rspec './spec/lib/dotiw_spec.rb[1:4:15]' # A better distance_of_time_in_words #distance_of_time_in_words should be 10 months, 4 weeks, and 2 days
rspec './spec/lib/dotiw_spec.rb[1:4:34:6]' # A better distance_of_time_in_words #distance_of_time_in_words without finish time should be 5 months, 2 weeks, and 1 day

Also to_time is parsed differently, even when setting the timezone, e.g.

$ TZ='Europe/Dublin' bundle exec irb
require './lib/dotiw'
Time.zone = 'UTC'
'2001-05-01'.to_time.utc 
# => 2001-04-30 23:00:00 UTC
Time.parse('2001-05-01').utc
# => 2001-04-30 23:00:00 UTC
'2001-05-01'.to_time(:utc)
# => 2001-05-01 00:00:00 UTC

When working with dates, the calculation should do the calculation as dates, instead of converting them to times.
Alternatively, another set of functions should be added, e.g. distance_of_date_in_words

If your app doesn't care at all about timezones, a workaround is to set the TZ environment variable, e.g. ENV['TZ'] = 'UTC'

[dblock]

I would like this to be documented/improved. Please contribute!