Modify ↓
Opened 18 years ago
Closed 18 years ago
#6028 closed defect (fixed)
Milestone with date 09/30/07 leads to iCalender export with 09/29/07
| Reported by: | Owned by: | Christian Boos | |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.11 |
| Component: | roadmap | Version: | devel |
| Severity: | minor | Keywords: | roadmap icalender |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
When I set the date of a milestone to 09/30/07 it gets exported to and iCalender file as 09/29/07
Attachments (1)
Change History (7)
comment:1 by , 18 years ago
| Owner: | changed from to |
|---|---|
| Severity: | normal → minor |
| Status: | new → assigned |
by , 18 years ago
| Attachment: | render_ics_in_req_tz-r6011.diff added |
|---|
use trac.datefmt utilities when producing the iCal rendering of the roadmap
comment:4 by , 18 years ago
| Keywords: | review added |
|---|
Ok, patch updated. The DTSTAMP is UTC and the DTSTART is produced using the user's timezone.
comment:6 by , 18 years ago
| Keywords: | review removed |
|---|---|
| Resolution: | → fixed |
| Status: | assigned → closed |
Thanks for the feedback. Patch committed in r6012.
Note:
See TracTickets
for help on using tickets.



I think I see the problem:
datetimewith A's tzinfotrac.util.datefmt.to_timestamp). This is a "neutral" date representation, the original timezone information is lost.datetimewith the utc tzinfomilestone.due.timetuple()which is the date in UTC time, where we should take user B's timezone into consideration.So we should either shift the timezone (
due.astimezone(tzinfo)) or rather use ourdatefmtutilities which can take care of this.