| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000628 | v3.0 Release | [All Projects] General | public | 2010-11-17 12:15 | 2013-10-31 06:19 | ||||
| Reporter | opto | ||||||||
| Assigned To | caseydk | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | 3.0.0 | |||||||
| Summary | 0000628: timezone handling confusing and incorrect upon dP upgrade | ||||||||
| Description | Apparently, 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) | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
opto (manager) 2010-11-17 12:17 |
to summarise: this problem makes db times inconsistent for times before upgrade/after upgrade |
|
caseydk (administrator) 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? |
|
opto (manager) 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 |
|
caseydk (administrator) 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. |
|
caseydk (administrator) 2011-11-26 22:39 |
Resolved in 2214, will be in the v3.0 release; |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-11-17 12:15 | opto | New Issue | |
| 2010-11-17 12:17 | opto | Note Added: 0001350 | |
| 2010-11-24 23:35 | caseydk | Project | v2.1 Release (Closed) => v2.2 Release (Closed) |
| 2010-11-24 23:48 | caseydk | Severity | block => major |
| 2010-12-15 21:55 | caseydk | Project | v2.2 Release (Closed) => v2.3 Release (Closed) |
| 2011-02-23 22:55 | caseydk | Note Added: 0001673 | |
| 2011-02-24 04:51 | opto | Note Added: 0001680 | |
| 2011-02-24 06:19 | caseydk | Note Added: 0001681 | |
| 2011-03-22 12:04 | caseydk | Project | v2.3 Release (Closed) => v2.4 Release (Closed) |
| 2011-07-18 12:23 | caseydk | Project | v2.4 Release (Closed) => v3.0 Release |
| 2011-11-26 22:39 | caseydk | Note Added: 0002326 | |
| 2011-11-26 22:39 | caseydk | Status | new => resolved |
| 2011-11-26 22:39 | caseydk | Resolution | open => fixed |
| 2011-11-26 22:39 | caseydk | Assigned To | => caseydk |
| 2013-08-28 11:13 | caseydk | Fixed in Version | => 3.0.0 |
| 2013-10-31 06:19 | caseydk | Status | resolved => closed |
| Issue History |