Having the same problem with OS X 10.6.1, Safari 4.0.3 (6531.9). Yikes! I know I edited a few entries, and never noticed this.

We were able to replicate something similar but only on a specific date 25 of october. That's the day when our server changed to winter time ( from GMT +3 to GMT +2 ). Only time entries on that day ( actually only those that start when the time was gmt+3 and end when the time was gmt+2 ) are affected.


We will fix this by setting our server not to use DST and stay on GMT+2 all the time.


Just to make sure, if i am correct in what i said above then you will not be able to replicate the bug on other dates ( for example today ) and also if you look at the affected entries the "From-To" field is correct but the "Duration" field is not calculated correctly.


Can you please confirm?

Sorry for the delay, I have not been able to replicate. Daylight savings, always a bummer. Thanks for looking in to this.

Thank you for the feedback

I am having this problem for my entries on Saturday the 27th and Sunday the 28th, only I'm losing an hour. Every time I enter something in the timesheet on these days it is moving it up one hour. I am very distressed about this! I need to have absolute confidence my time entries are accurate so I can bill my clients on the 1st. Please respond asap.

Looking into it. It's related to the time being changed to summer time this weekend. Only (display of) entries in a short time frame is affected. More details (solutions) in a few minutes

We checked the this for your account and here is what we found:

When adding entries in the period between March 27th 6pm - March 28th 4am, the start/end time is shifted by 1 hour. This still counts as 1 hour in reports (just the timeframe displayed is different from what it should be) and does NOT affect the "Total Hours" of your reports.


Temporary Solution:

a) Edit your time entries for 27th-28th so that they don't fall into the 6pm - 4am timeframe.

b) If you need to have entries in the 6pm-4am timeframe, edit those specific entries and add one hour to start/end time to compensate for the shift.


This wired behavior surfaces only twice a year (October and March, on weekends, and for a short period of time which is usually late evening early morning) when the time shifts +/- 1 hour due to Daylight Saving Time. It DOES NOT affect your time logs in any way on any other day.


PS: We will still try to find a "workaround" for this "rare" bug

Wouldn't it be simpler to use UTC and allow user to pick when is date change hour?