Opened 6 years ago

Closed 6 years ago

# Depend on duplicated configuration to use correct timezone

Reported by: Owned by: rjollos hasienda normal WikiTicketCalendarMacro normal timezone locale 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.

### comment:1 Changed 6 years ago by rjollos

• Owner changed from rjollos to hasienda

### comment:2 follow-up: ↓ 3 Changed 6 years ago 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.

### comment:3 in reply to: ↑ 2 Changed 6 years ago by hasienda

• Status changed from new to assigned
• Summary changed from Does not use correct timezone to Depends on duplicated configureation to use correct timezone
• Type changed from defect to enhancement

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.

### comment:4 Changed 6 years ago by hasienda

• Resolution set to fixed
• Status changed from assigned to closed

(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.

### comment:5 Changed 6 years ago by rjollos

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

### comment:6 Changed 6 years ago by rjollos

• Resolution fixed deleted
• Status changed from closed to reopened

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.

### comment:7 Changed 6 years ago 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.

### comment:8 follow-up: ↓ 10 Changed 6 years ago 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.

### comment:9 Changed 6 years ago by rjollos

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

### comment:10 in reply to: ↑ 8 ; follow-up: ↓ 11 Changed 6 years ago by hasienda

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.

### comment:11 in reply to: ↑ 10 Changed 6 years ago by 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?

### comment:12 Changed 6 years ago by rjollos

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

### comment:13 Changed 6 years ago 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.

### comment:14 Changed 6 years ago by hasienda

• Resolution set to fixed
• Status changed from reopened to closed

(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.