Internally we aggregate all tracked time into days based on the time zone of the Organization. This aggregated data is then used by the Reports, Team Payments, Payroll, and Weekly limit systems within Hubstaff.
Generally you should never need to change the time zone of an organization unless you want all future data to be interpreted under the new time zone.
Reports, Team Payments, and Payroll
When Hubstaff calculates the time tracked it uses the aggregated data. Changing the time zone of the organization only affects new activity data tracked after the time zone change.
If you need to view activity data in a different time zone, please use the Detailed Activities View, as those allow switching the presentation time zone between the organization and the user being viewed.
When a weekly limit is being calculated and sent to the client the activity is totaled by using the aggregated data for the week. Changing the time zone will affect the start time and stop time the client uses to locally validate the weekly limit.
An organization is currently set to UTC.
A user has a weekly limit for the week of June 20th, 2016. This would run 2016-06-20 00:00 up until just before 2016-06-27 00:00.
If the user tracks time from 2016-06-20 04:00 through 2016-06-20 12:00 (8 hours). That time will be marked as belonging to 2016-06-20 (aggregated).
The Organization owner changes the timezone to America / Los Angeles (UTC offset -0700).
The weekly limit as seen by the client is now 2016-06-20 07:00 up until just before 2016-06-27 07:00
However the client still sees the same amount of “logged time” as the activity tracked from 04:00 until 07:00 UTC is still marked as belonging to 2016-06-20.
Why we do this
We are utilizing this method of handling activities so that past activity will not “shift” between days when viewing past reports. And so that past weekly limits will retain the same time logged against them even if the time zone changes.
Also aggregating the data this way improves the performance of the reports as we have smaller indexes and less records to query against.