#6028 and r6012
Eli Carter
I'm coming to the conclusion that r6012 isn't sufficient to solve #6028.
Having a due /date/ for a milestone is ambiguous once you have users in
different timezones. The due date is taken to be midnight in the setting
user's timezone of that day. When another user only one timezone away looks
at that same due date, they may see a different date.
If we specify that the date given is taken to be midnight UTC on that date,
the date the user sees may not match the date entered.
I think we really need to make the due date be a date and time. That avoids
the ambiguity. (It has a plus for businesses that want to specify midnight
or 'end-of-business' of a day as when it is due.)
Comments, thoughts, etc?
Eli
Morris
user enter the day and time. That would be converted internally to
epoch time based on the entering user's timezone. Then it would be
displayed to users based on their own timezones."
+1 to adding a time field to Milestone duedate.
-M
Christian Boos
> All,
>
> I'm coming to the conclusion that r6012 isn't sufficient to solve #6028.
>
> Having a due /date/ for a milestone is ambiguous once you have users in
> different timezones. The due date is taken to be midnight in the setting
> user's timezone of that day. When another user only one timezone away looks
> at that same due date, they may see a different date.
>
> If we specify that the date given is taken to be midnight UTC on that date,
> the date the user sees may not match the date entered.
>
If you're talking about different users, then there's no way to ensure
they will all see the same date, whichever time of the day is chosen.
> I think we really need to make the due date be a date and time. That avoids
> the ambiguity. (It has a plus for businesses that want to specify midnight
> or 'end-of-business' of a day as when it is due.)
>
That's a slippery slope leading Trac down the way to micromanagement ... ;-)
More seriously, I don't see how picking up a different starting point in
the day would help in this case. There will still be users that will see
a different "date" than the one which was originally entered. What is
useful however is to remind people about the timezone issues, so maybe
what we can add to r6012 is to show the full datetime information
instead of just the date. That's already the case for all displayed
dates in tooltips btw., just not done in the iCal output.
Maybe the "perfect" solution would be to show to everybody the due date
using the timezone offset of the user who has set that due date (the
release manager?), but there's no way this could be done using the
current schema.
-- Christian
John Hampton
> Eli Carter wrote:
>> I think we really need to make the due date be a date and time. That avoids
>> the ambiguity. (It has a plus for businesses that want to specify midnight
>> or 'end-of-business' of a day as when it is due.)
>
> That's a slippery slope leading Trac down the way to micromanagement ... ;-)
How is being able to specify a a due time during a given day,
micromanagement?
> More seriously, I don't see how picking up a different starting point in
> the day would help in this case. There will still be users that will see
> a different "date" than the one which was originally entered. What is
> useful however is to remind people about the timezone issues, so maybe
> what we can add to r6012 is to show the full datetime information
> instead of just the date. That's already the case for all displayed
> dates in tooltips btw., just not done in the iCal output.
I think I'm getting confused as to what the issue is. I'm +1 for adding
time information also. That way I can specify that milestone X needs
to be done by 5PM PST on October 31, 2007, or whenever.
Now, if Eli then takes a look at the due date, he'll see that it's due
at 7PM CST on October 31, 2007. This is fine, as it's the same time.
I don't really see how this affects the current situation, as that
simply picks midnight as the due date. I that was midnight EST, then
it'll be 9pm PST for me. I don't see how this is an issue? It's still
due at the same time. Any given time in one part of the world, is a
different time in another part of the world.
Now, I'm +1 on the change, as it gives people more granularity, which is
nice. Especially since, for businesses at least, they'll want to pick
around 5pm as the due time.
-John