Anonymous Login
2020-07-12 11:18 PDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001329Pending RequestsCore Infrastructurepublic2014-04-05 17:34
Assigned To 
Product Version 
Target VersionFixed in Version 
Summary0001329: Changing start or end date with pop up calendar has TZ issues
DescriptionTesting with git e1aca52fa4ad4e308689b0483446b2905e2a1f17 as at 2013-06-09
Changing project start and/or end date using the pop up calendars will result in a time offset of +11h when saving from locale UTC+12h.
Existing start and stop times are fine according to locale.
Changing the date will add +11hr to the nominated date.
Additional InformationInvestigation into database entry for modification time shows entry time stamped at UTC+1h. Correct time stamp should have been UTC.
Server system locale set to Pacific/ Auckland.
Other applications correctly log changes as UTC (Mantis does this) but W2p add 1h.

Still think there's some fundamentals not quite right.
Timestamp should always be UTC
Data should be UTC in DB but displayed in user locale.
Example (for locale UTC+12)
Start date = 2013-06-10 0800, should store as 2013-06-09 2000 but shows in DB as 2013-06-09 2100.
Stop date = 2013-07-01 1600, should store as 2013-07-01 0400 but shows in DB as 2013-07-01 0500
Because an incorrect offset is used on displaying the start and stop times it looks correct to the user in the w2p view
TagsNo tags attached.
Attached Files




opto (manager)

bind does only changes times in the CTask overload of bind, not in the projectdesigner overload.

Also, we extract the times from the $POST beforre any bind.

Most likely, we need to convert the times from the post back to system TZ before store.


opto (manager)

see my branch id1329 on github for solution.


sasquatch58 (reporter)

Last edited: 2013-06-29 03:31

Looks like DB date/ time values are OK for normal task entry/ edit/ display with correction posted here but the issue with using the popup calendar in designer as noted above is still a problem with the popup calendar entries. I suspect there's a TX adjustment not applied somewhere.

I'd also comment that moving a task by x days doesn't force a recalc of when the task falls over a weekend. Task moved by 3 days when original start is a Wednesday, should give new start day = Monday.


opto (manager)

yes, the weekend recalc is not consistent, see my post in the forum

On the other hand, we need to be able to switch this feature off, otherwise we will not be able to do any tasks on a weekend.
'catch my plane on Sunday' would automatically be shifted to the next Monday.
So in some contexts, this is desirable, in others not.

Can also create crazy timezone issues if a day is Monday in one TZ but not in another, ans that user edits the task


caseydk (administrator)

I think this should resolve it:

And I've switched off most of the working hours checks with the assumption that if you schedule something outside working hours, you're doing it on purpose.. *but* if you use "calculate end date" anywhere, it will always respect working hours.

Basically, the core system will assume that you mean working hours until you choose something differently.. then it doesn't touch that particular time.

-Issue History
Date Modified Username Field Change
2013-06-09 02:52 sasquatch58 New Issue
2013-06-09 10:43 opto Note Added: 0002942
2013-06-09 10:43 opto Status new => feedback
2013-06-09 12:45 opto Note Added: 0002943
2013-06-29 03:28 sasquatch58 Note Added: 0002951
2013-06-29 03:31 sasquatch58 Note Edited: 0002951
2013-06-30 07:55 opto Note Added: 0002952
2013-08-03 22:46 caseydk Project v3.0 Release => Pending Requests
2013-08-03 22:48 caseydk Note Added: 0002985
2014-04-05 17:34 caseydk Category General => Core Infrastructure
+Issue History