Should use 12:00 for due time instead of 0:00

[brons_tractrac@…]

Right now Trac uses 0:00 GMT for its internal date calculations. This should be changed to 12:00 GMT.

Picture two workers: Sam and Ralph. Sam is in Sao Paulo at GMT-2, Ralph is in Madrid at GMT+1. When Ralph enters a milestone due on 11/14/07, right now Trac displays it to Sam as 11/13/07. They are separated by only 3 hours, yet Trac is telling them it's due on different days!

If Trac used 12:00 GMT, both Sam and Ralph would see 11/14/07, and they would spend less time on email trying to figure out why they never quite agree on what day anything is due.

[cboos]

Hm, strange nobody made that proposal before (in particular in the googlegroups:trac-dev:4187c28512541cf0 discussion).

While this won't help for the most exotic time zones (-12 and +12/+13), that change will probably be an improvement for 99.99% of the cases.

[salzer@…]

Replying to cboos:

Hm, strange nobody made that proposal before (in particular in the googlegroups:trac-dev:4187c28512541cf0 discussion). While this won't help for the most exotic time zones (-12 and +12/+13), that change will probably be an improvement for 99.99% of the cases.

I'd rather like to have a milestone deadline as date and time (not just a day, as this is the source of this problem), and have this time displayed as the milestone due deadline. Next, I'd like to have a default time configurable, so there is no hardcoding involved, and it is still convenient enough for most people. If possible, configurable via webadmin.

Even if you don't have project participiants (not only developers!) from different timezones, a "milestone is due on tuesday" is pretty vague in an environment involving e.g. a paying customer and a project manager. And it is not always possible to tell the customer a deadline is always meant as 0:00 GMT, or 12:00 GMT, or 8:45 whatever timezone, and keeping a straight face. :-)

Otherwise, if you stick to days, I'd oppose the 12:00 calculation base, since the 0:00 base has the benefit of lesser complexity: A milestone switches to overdue at a time easy to explain (to yourself, if you have to). If it magically switches in the middle of the day, it adds to overall complexity, and nobody knows why the due status changed right now -- which will generate tickets here, add to the required documentation and, for the users, the stuff (quirks?) to learn. In addition, a transition to a time-based milestone due calculation would be even harder in future, given you want to provide upgrade paths from several Trac versions.

Regards, /Till/

[wangchun <wangchun@…>]

per /Till/ I oppose the 12:00 proposal. It is confusing.I think adding a new due time field would be a more reasonable solution.

[cboos]

Ok, so what about specifying date and time (like we do for versions), and we preset the time to, say, 8:00 in the localtime of the user creating the milestone (the time will be stored as GMT, as always).