Ticket #7473 (closed enhancement: fixed)

Opened 3 years ago

Last modified 3 years ago

Depend on duplicated configuration to use correct timezone

Reported by: rjollos Assigned to: hasienda
Priority: normal Component: WikiTicketCalendarMacro
Severity: normal Keywords: timezone locale
Cc: Trac Release: 0.11

Description

The server that hosts my Trac instance is 2 hours ahead of my location. I have the following setting in trac.ini: 

[trac]
default_timezone = US/Pacific

It is currently 23:30 on 10-Aug and WikiTicketCalendarMacro is showing the highlighted day as 11-Aug, so I'm assuming that the default_timezone is not being used. I've seen this issue with other plugins and macros.

I haven't looked closely at the code, but the timezone preference can be obtained from formatter.req.tz or the tzinfo.localize() method may be useful here.

Attachments

WikiTicketCalendarMacro.py (26.6 kB) - added by rjollos on 08/23/10 10:05:53.

Change History

08/11/10 09:04:38 changed by rjollos

  • owner changed from rjollos to hasienda.

(follow-up: ↓ 3 ) 08/11/10 09:08:09 changed by rjollos

I just noticed the ticket.due_field.utcoffset parameter, but I have to wonder if it would be better to just use the Trac preference.

(in reply to: ↑ 2 ) 08/11/10 13:51:56 changed by hasienda

  • keywords set to timezone locale.
  • status changed from new to assigned.
  • type changed from defect to enhancement.
  • summary changed from Does not use correct timezone to Depends on duplicated configureation to use correct timezone.

Replying to rjollos:

I just noticed the ticket.due_field.utcoffset parameter, but I have to wonder if it would be better to just use the Trac preference.

Sure. That duplicated configuration for WikiTicketCalendarPlugin? was introduced knowingly as a quick-n-dirty solution, once I recognized the need for timezone-dependent time correction. Frankly I wasn't able to instantly localize where to get this info from. I'll dig into this again and make the option obsolete again by better code. Thanks for the hint and for pushing me into this.

08/12/10 00:47:30 changed by hasienda

  • status changed from assigned to closed.
  • resolution set to fixed.

(In [8356]) WikiTicketCalendarMacro: Use Trac's native timezone setting, closes #7473.

This obsolets the interim 'ticket.due_field.utcoffset' configuration option. Timestamp creation methods based on Python's 'time' module are substituted with cleaner code, so we do internally use 'datetime' objects for time stamps almost everywhere.

08/12/10 01:44:13 changed by rjollos

Thanks for the quick fix. I'm testing it out and will report if any issues are found.

08/12/10 06:52:51 changed by rjollos

  • status changed from closed to reopened.
  • resolution deleted.

It looks like there is a minor issue with this. The milestones are displayed one day early on the calendar. For example, I have 3 milestones due this Friday, and they are shown as being due on Thursday.

08/14/10 00:16:40 changed by hasienda

  • summary changed from Depends on duplicated configureation to use correct timezone to Depend on duplicated configuration to use correct timezone.

Thank you for the additional report. This may be only recognized in case local time is behind UTC, so that I can't reproduce here in Europe, unless I do switch the time zone to some place west from Greenwich. Never dreamed of doing so, anyway this is checked now.

(follow-up: ↓ 10 ) 08/23/10 10:05:34 changed by rjollos

I've tested the version you sent me by email on 2010-08-14, and it appears to be working great! In fact, just to be sure, I will upload that version to this ticket.

I tested at around 00:45 AM in my timezone (US/Pacific), and observed that the milestones were displayed on the correct days and the correct day was highlighted as well. I then set the default timezone to be one hour behind my timezone (US/Alaska), and observed that the previous day was highlighted.

Is there an option for determining if the week starts on Sunday or Monday? That is, the option would determine if the first column of the calendar displays Sunday or Monday. Currently, it displays Sunday on my development instance of Trac.

08/23/10 10:05:53 changed by rjollos

  • attachment WikiTicketCalendarMacro.py added.

08/23/10 10:21:47 changed by rjollos

In the course of doing this testing, I discovered a bug in Trac and reported it here t:#9582.

(in reply to: ↑ 8 ; follow-up: ↓ 11 ) 08/23/10 11:11:17 changed by hasienda

Replying to rjollos:

I've tested the version you sent me by email on 2010-08-14, and it appears to be working great! In fact, just to be sure, I will upload that version to this ticket.

Perfect. So I'll push the changes leading to that version for both 0.11 and 0.12 branch out tonight. Thanks for the feedback.

... Is there an option for determining if the week starts on Sunday or Monday? That is, the option would determine if the first column of the calendar displays Sunday or Monday. Currently, it displays Sunday on my development instance of Trac.

It is, but hard-coded and mentioned to affect the whole system as far as I recall. If this is relevant to you, as it looks like, since you're asking, I'll have a look and come back at you later.

(in reply to: ↑ 10 ) 08/23/10 11:17:46 changed by rjollos

Replying to hasienda:

Replying to rjollos:

Currently, it displays Sunday on my development instance of Trac.

Whoops, what I should have said is, "it displays Monday on my development instance of Trac." What I am accustomed to though is seeing calendars that start on Sunday.

Do you mean hard-coded in Trac, or hard-coded in WikiTicketCalendarMacro?

08/23/10 22:17:50 changed by rjollos

I added some follow-up to t:#9582 that may prove relevant to this ticket.

08/23/10 23:33:43 changed by hasienda

Yes, I noticed this day flipping as well when testing. Good analysis. WikiTicketCalender? will certainly profit from changing due time from 0:00 to 12:00.

08/24/10 00:19:55 changed by hasienda

  • status changed from reopened to closed.
  • resolution set to fixed.

(In [8434]) WikiTicketCalendarMacro: Change usage of tzinfo for time stamp creation, closes #7473 - again.

Major code rework to straighten up the logic considerably. This should fix another issue raised with milestone displayed at wrong day. Thanks to Ryan J. Ollos for pre-release testing this non-trivial subject.

Add/Change #7473 (Depend on duplicated configuration to use correct timezone)




Change Properties
Action