Anonymous Login
2022-12-05 15:45 PST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001146v3.0 Release[All Projects] Generalpublic2013-08-28 11:18
Assigned Tocaseydk 
Product Version 
Target VersionFixed in Version3.0.0 
Summary0001146: Timezone issues in Tasks
DescriptionUser pref timezone set to UTC+12 (NZST - daylight saving is OFF)
Enter a task - start date is NZST 2012-06-04 08:00:00, end date is NZST 2012-06-08 17:00:00.
w2p database entry for this task has task_start_date 2012-06-03 21:00:00 and task_end_date 2012-06-08 06:00:00. These are wrong if the databse is meant to be storing dates in UTC. For UTC (GMT/Zulu) task_start_date should be 2012-06-03 20:00:00 and task_end_date 2012-06-08 05:00:00 (subtracting 12h in both cases).
Task View displays the database entries unchanged - does not compensate for user pref and reloads these for editing. This is a regression from V2.31 and V2.4 as far as display goes.
TagsNo tags attached.
Attached Files




sasquatch58 (reporter)

To clarify working day preferences are set to Mon - Fri Start 0800, End 1700.


Korkonius (reporter)

I cannot assign issues unfortunately, but i am working on the timezones now...


sasquatch58 (reporter)

Refer to w2p forum for specifc detail


project_manager (reporter)

The task time display was in the w2p.3.x-2213 version correct.
Installed now the w2p.3.x-2470 version:
- user working hours: 9.00-17.00.
- local user hour: GMT+1h (Berlin).
- database task_time: 8.00 (stored as GMT) ---> ok!
- task displayed in project view: 8.00 (GMT) ---> wrong!
- edit this task: 9.00 (GMT+1h) ---> ok!
---> store this task: stored in dB as 8.00 (GMT) ---> ok!


project_manager (reporter)

I also dont understand why my "default timezone" is GMT+2 (sysadmin)
shown under "System Status" ???


sasquatch58 (reporter)

Your w2p System default timezone is derived from the System Timezone set in w2p System Configuration. This will override any server timezone settings set in php.ini config.


project_manager (reporter)

"w2p System default timezone is derived from the System Timezone set in w2p System Configuration..."
---> ok, but I set MY timezone in sysadmin to GMT+1 (Berlin, my USER tz).
---> So, DEFAULT timezone = USER tz + 1h ???


caseydk (administrator)

This one solves a good chunk of this problem: but I'm not 100% convinced that the timezones are working completely as expected..

Please note that this solution is *only* available in the v3.0-pre development and can't be applied to any version earlier (eg 2.4, 2.3, etc).


caseydk (administrator)

Further testing underway..


caseydk (administrator)



sasquatch58 (reporter)

Sorry Keith, latest build (from git/ master on 3 Nov) worse than before with tasks & timezones.
Create a task, set start date & duration of 10d & finish date is calculated as the following day :-(. Start time offsetting from expected 0800h (UTC+13) to 0600 UTC as recorded in the database - local tz incorrectly displayed. Note last update time correctly recorded in database by again displayed to user in UTC not local tz.


caseydk (administrator)


Twelfth try is the charm?

It appears that somewhere along the way, the system decided to start using its own timezones to do conversions instead of the user-selected one. I believe it was an error on my part.

Or the system has gained sentience and we're in serious trouble..

-Issue History
Date Modified Username Field Change
2012-06-03 03:53 sasquatch58 New Issue
2012-06-03 03:56 sasquatch58 Note Added: 0002545
2012-06-05 22:04 Korkonius Note Added: 0002553
2012-06-28 17:31 sasquatch58 Note Added: 0002559
2012-06-30 07:38 project_manager Note Added: 0002562
2012-06-30 07:47 project_manager Note Added: 0002565
2012-06-30 16:22 sasquatch58 Note Added: 0002569
2012-07-01 13:26 project_manager Note Added: 0002570
2012-08-07 21:06 caseydk Note Added: 0002628
2012-08-07 21:07 caseydk Note Added: 0002629
2012-08-07 21:07 caseydk Assigned To => caseydk
2012-08-07 21:07 caseydk Status new => feedback
2012-11-01 22:18 caseydk Note Added: 0002679
2012-11-01 22:18 caseydk Status feedback => resolved
2012-11-01 22:18 caseydk Resolution open => fixed
2012-11-02 19:15 sasquatch58 Note Added: 0002681
2012-11-02 19:15 sasquatch58 Status resolved => feedback
2012-11-02 19:15 sasquatch58 Resolution fixed => reopened
2012-11-24 17:04 caseydk Note Added: 0002710
2012-11-24 17:04 caseydk Status feedback => resolved
2012-11-24 17:04 caseydk Resolution reopened => fixed
2013-08-28 11:14 caseydk Fixed in Version => 3.0.0
2013-08-28 11:18 caseydk Status resolved => closed
+Issue History