Anonymous Login
2019-04-19 03:28 PDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000628v3.0 Release[All Projects] Generalpublic2013-10-31 06:19
Reporteropto 
Assigned Tocaseydk 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
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

-Relationships
+Relationships

-Notes

~0001350

opto (manager)

to summarise: this problem makes db times inconsistent for times before upgrade/after upgrade

~0001673

caseydk (administrator)

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 (manager)

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 (administrator)

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 (administrator)

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