MantisBT - v3.0 Release
View Issue Details
0000628v3.0 Release[All Projects] Generalpublic2010-11-17 12:152013-10-31 06:19
Reporteropto 
Assigned Tocaseydk 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version3.0.0 
Summary0000628: timezone handling confusing and incorrect upon dP upgrade
DescriptionApparently, one can set a user timezone default. an user timezone AND a system timezone - this should be more clearly mentioned in the wiki (have done that on installation page/getting started).

Maybe the tooltip in system admin could give a hint at the triple settings?

Whoever outside the US changes the system settings will have problems with the times in the db.

As I would typically assume that w2p is installed in a consistent time setting, one could argue whether changing the system timezone should not ask whether to change all other timezones as well.

Otherwise, for installers outside the US, the procedure is:

1) change system timezone
2) change user default timezone
3) change timezone for the admin account that has already been created.

feels a bit strange, especially, if no guidance is given.

BUG: Actually, the dP upgrade script has a bug: I have exactly this inconsistency - system TZ is Berlin, user default TZ and all user TZ are US timezone. So in effect, all my times BEFORE the upgrade will be identical to webserver timezone (=Berlin, OK), all my times after will have the offset created by the upgrade script - oh god, that will be fun to correct. Well - maybe not: all db times after creation time of db (see filesystem) will be wrong.


In task view, everything looks alright: if I enter 9am, the db saves 3pm but converts to 9am upon task view creation. Problem shows in the ical feed - there, 3pm is put into the feed for GMT time of task.
Correct upgrade procedure from dP: ask for TZ, set it identical for system, user default, all users (maybe also ask whether server TZ is different)



TagsNo tags attached.
Attached Files

Notes
(0001350)
opto   
2010-11-17 12:17   
to summarise: this problem makes db times inconsistent for times before upgrade/after upgrade
(0001673)
caseydk   
2011-02-23 22:55   
I've been playing with ideas on how to solve this one.. I'm not convinced any of them are 100%.

I think the most reasonable solution is to catch the users' and system timezones when they initially upgrade to web2project. Then we assume they've put in times (tasks, events, etc) relative to their own timezone and we simply mass-update to GMT/UTC.

A mass update like this makes me nervous though:

What happens if we're wrong?

Or if multiple people (across multiple timezones) were putting in data relative to their own timezone? We may be able to mitigate this by looking at the task/event owner and matching the conversion accordingly.

Or if the person upgrading isn't the person who put in the tasks, events, etc? We could fall back to task/event owner here too.

Tips? Ideas? Criticism?
(0001680)
opto   
2011-02-24 04:51   
just ask the person doing the conversion?

There are some cases where we can do it safely.
In all other cases, the user just needs to know and maybe be allowed to decide whether to do it automatically or not.

If he refuses, things will be inconsistent (at least in ical feed, it may not be noticable if the same server is used in the task .. screens).
iF HE SAYS YES - AGAIN; IT CAN BE OK; OR NOT: (sorry for the capitals..).

His problem to solve it if he set it wrong before update, but just let him know.
Also, he can save db and try both, to see what is more consistent.


Klaus
(0001681)
caseydk   
2011-02-24 06:19   
Reasonable..

We can also make this a little less risky if we show the user a handful of upcoming events/tasks showing the date before & after a potential change.
(0002326)
caseydk   
2011-11-26 22:39   
Resolved in 2214, will be in the v3.0 release;

Issue History
2010-11-17 12:15optoNew Issue
2010-11-17 12:17optoNote Added: 0001350
2010-11-24 23:35caseydkProjectv2.1 Release (Closed) => v2.2 Release (Closed)
2010-11-24 23:48caseydkSeverityblock => major
2010-12-15 21:55caseydkProjectv2.2 Release (Closed) => v2.3 Release (Closed)
2011-02-23 22:55caseydkNote Added: 0001673
2011-02-24 04:51optoNote Added: 0001680
2011-02-24 06:19caseydkNote Added: 0001681
2011-03-22 12:04caseydkProjectv2.3 Release (Closed) => v2.4 Release (Closed)
2011-07-18 12:23caseydkProjectv2.4 Release (Closed) => v3.0 Release
2011-11-26 22:39caseydkNote Added: 0002326
2011-11-26 22:39caseydkStatusnew => resolved
2011-11-26 22:39caseydkResolutionopen => fixed
2011-11-26 22:39caseydkAssigned To => caseydk
2013-08-28 11:13caseydkFixed in Version => 3.0.0
2013-10-31 06:19caseydkStatusresolved => closed