SiT! Bugs - SiT!
View Issue Details
0001000SiT!billingpublic2009-10-25 10:202011-08-08 12:52
ivan 
 
normalminorhave not tried
confirmedopen 
 
 
0001000: Activities start counting at 1hr
When starting a new activity the Duration begins at 00:01:00:00 (1 hour)

Not sure if this is related to the change in the UK from BST to GMT... I had the same issue last night while still on BST... now on GMT.
No tags attached.
related to 0001676resolved paulh Activity page "Duration" column is wrong/misleading 
Issue History
2009-10-25 10:20ivanNew Issue
2009-10-25 12:14paulhNote Added: 0002136
2009-10-25 12:31ivanNote Added: 0002137
2009-10-25 14:31paulhNote Added: 0002139
2010-02-20 19:34paulhNote Added: 0002417
2010-02-20 19:34paulhStatusnew => confirmed
2010-08-22 12:26TomseNote Added: 0003365
2011-08-08 12:52ivanNote Added: 0004189
2011-08-08 12:52ivanRelationship addedrelated to 0001676

Notes
(0002136)
paulh   
2009-10-25 12:14   
We used to have this issue ages ago though I thought I'd fixed it.

The problem last time was to do with the js variable being set to the time on the server and the count up using local time (I think).

I can't repro this on my machine (and couldn't last time either) so was/is abit of a hard one to track down.
(0002137)
ivan   
2009-10-25 12:31   
Could the JS implement a check to ensure that it always begins at 00:00 or is that not possible?
(0002139)
paulh   
2009-10-25 14:31   
Yeah if the JS has the server time as a variable and on page load another variable was set for WS time then we would know the difference and be able to show more accurately.

This is something I thought I'd done though looking through tasks.php can't see the code I though I wrote so either its gone amiss somewhere or I never actually wrote it ;-)
(0002417)
paulh   
2010-02-20 19:34   
We need to handle this and also problems where the client are server times aren't in sync, last week saw an activity which was -3 minutes
(0003365)
Tomse   
2010-08-22 12:26   
I haven't been able to reproduce the problem either (sit svn between 3.62-3.63)
(0004189)
ivan   
2011-08-08 12:52   
I think this may be the same bug as reported in 0001676 and not actually relating to timezones. Worth checking anyway.