Defect #16482

Wrong search query for timelog, when timezone not UTC

Added by Alexander Maslov almost 4 years ago. Updated about 1 month ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Time tracking
Target version:-
Resolution: Affected version:2.5.1

Description

How to reproduce:

0. You are need to have server/devbox timezone set to UTC+X, where X is positive.
1. At 00:30 I'm create a timelog entry.
2. Right after this at a timelog reports page I'm select option to show only today timelog entries.
3. After pressing the search button, I'm can't see the timelog entry.
4. After the X time after 00:00, I'm can press the search button and can see the timelog entry as it need to be.

How to fix:

1. Replace all Date.today to Time.zone.today.

Patch: WIP, writing tests, investigating side effects.

Screen Shot 2017-02-21 at 4.05.14 PM.jpg (224 KB) Jamila Khan, 2017-02-21 22:09


Related issues

Related to Redmine - Patch #22320: Respect user's timezone when comparing / parsing Dates Closed
Related to Redmine - Defect #19033: Filters that utilize date/time ignore user's UTC offset Closed
Related to Redmine - Defect #23189: Spent time by filter, offset by one day New
Related to Redmine - Feature #23630: Migrate to Rails 5.1 Closed
Duplicated by Redmine - Defect #25822: 'Spent time' report is timezone-dependent (which it shoul... Closed
Duplicated by Redmine - Defect #26156: Spent time not working correctly with user's zone differe... Closed

History

#1 Updated by Scott Macpherson over 3 years ago

I think I'm seeing the same issue manifesting itself in a slightly different way. The timezone on my Redmine server is set to UTC, and I've set config.active_record.default_timezone to :utc in config/enviroment.rb.

When I log work for local date 2014-10-01, but at a time when the UTC date is still 2014-09-30, attempting to view spent time where date is "today" doesn't return any results. Entering today's date rather than just "today" does return the correct records though.

#2 Updated by Jens Krämer almost 2 years ago

patch in #22320

#3 Updated by Jan from Planio www.plan.io almost 2 years ago

  • Related to Patch #22320: Respect user's timezone when comparing / parsing Dates added

#4 Updated by Jan from Planio www.plan.io almost 2 years ago

  • Target version set to Candidate for next minor release

#5 Updated by Toshi MARUYAMA almost 2 years ago

  • Related to Defect #19033: Filters that utilize date/time ignore user's UTC offset added

#6 Updated by Toshi MARUYAMA over 1 year ago

  • Status changed from New to Needs feedback
  • Target version deleted (Candidate for next minor release)

I think this issue is fixed by #22320, right?

#7 Updated by Jamila Khan 11 months ago

I'm afraid not.
We just upgraded to 3.3.2.stable from 3.1.2.stable and this issue just showed up.
This is still a problem.

Our server is set to GMT-5, and all date based queries done by users whose local time zone is set to GMT-6 through GMT-11 give incorrect days.
We have two workers in GMT-8 whose date based queries are not working.
Queries for tickets due "today" show tomorrow.
Changing the time zone to GMT-5 makes the issue disappear.

Environment:
Redmine version 3.3.2.stable
Ruby version 2.2.5-p319 (2016-04-26) [x86_64-linux]
Rails version 4.2.7.1
Environment production
Database adapter Mysql2

Please let me know if there are tests I can do that would help pinpoint the cause.

thanks,

#8 Updated by Jamila Khan 11 months ago

Example:
Server time zone GMT-5
User time zone set to GMT-8
Screenshot attached of query looking for tickets due 2/21/17, query returns tickets due 2/22/17.

#9 Updated by Toshi MARUYAMA 10 months ago

  • Status changed from Needs feedback to New

#10 Updated by Jamila Khan 10 months ago

Thank you for marking this as New, is there any other information that I can help provide for those who are able to fix this?
Does anyone know of a patch that I could apply in the meantime?

thanks,

#11 Updated by Toshi MARUYAMA 9 months ago

  • Related to Defect #23189: Spent time by filter, offset by one day added

#12 Updated by Jamila Khan 9 months ago

We just upgraded to 3.3.3.stable from 3.3.2.stable and this issue persists.

#13 Updated by Marius BALTEANU 9 months ago

It seems to be a Rails bug:
https://github.com/rails/rails/issues/3145
https://github.com/rails/rails/issues/6816

I looked in the Redmine code and everything looks fine for me until this line: source:trunk/app/models/query.rb#L1295 which returns for the date Mon, 20 Feb 2017 23:59:59 AKST -09:00 the value 2017-02-21 08:59:59.999999. I used "(GMT-09:00) Alaska" for user timezone and GMT-5 on the server to reproduce the issue.

From what I understand, the issue is fixed on Rails 5.

#14 Updated by Jamila Khan 9 months ago

Thank you!

It looks like Redmine doesn't support Rails 5 yet.
#23630

#15 Updated by Jamila Khan 8 months ago

Is there any way to fix this other than upgrading to Rails 5, which doesn't seem possible yet?

#16 Updated by Toshi MARUYAMA 8 months ago

#17 Updated by Toshi MARUYAMA 7 months ago

  • Duplicated by Defect #25822: 'Spent time' report is timezone-dependent (which it should not) added

#18 Updated by Jamila Khan 7 months ago

Thank you for relating this to the appropriate tickets.
That said, this is affecting the ability of our remote workers to effectively use redmine.
Does is appear there is anything we, as non-coders, could do other than wait for Redmine to support Rails 5?
It looks like #23630 is blocked by #19755 which looks pretty far down in the roadmap queue.

#19 Updated by Toshi MARUYAMA 7 months ago

  • Duplicated by Defect #26156: Spent time not working correctly with user's zone different from system's time zone added

#20 Updated by Martin Jungowski 7 months ago

Thank you Toshi for linking my ticket with this one. Despite searching for quite I while I somehonw failed to find this.

Anyway, I'm having the exact same problem. In addition to time zone it also seems to be affected by language selected in "My account"...

#21 Updated by Tyrone Hattingh 2 months ago

Hi there,

I just upgraded from 2.3.3 --> 3.4.3 (rails 4.2) -> latest version (rails 5.1) and this issue is still occurring, it does not appear to be an issue with Rails then. Any suggestions?

#22 Updated by Jamila Khan about 1 month ago

This is still affecting the ability of our remote workers to effectively use redmine.
Thank you to those who have tested newer versions of rails.
To devs: is there more information that you would need from any of us in order to track down the cause of the bug?

Also available in: Atom PDF