Should Start Time Set by Client or Server?

[nelsonic]

In our MVP we were setting the timer.start_time on the client as Date.now()
This is fine for an MVP because the whole point is to start testing the product ASAP with real people.

However if we are going to use this tool "for real" we need "integrity" of the start_time
to avoid people (trivially) setting it to a time in the past to "clock" more time against a task.
I think the only way we can do this is by defining the start_time on the server
(preferably automatically in the database layer with a reference to the Time Zone the client/device is in so we know if there needs to be an "offset")

Unless we want to give people the ability to define the start_time for their task
e.g: in the case where someone forgets to start the timer when they begin a task...?

Personally I think it opens up more issues than it resolves,
and if a person "forgets" to start the timer for a task
they are unlikely to "forget" more than a couple of times.

Also, our goal is to make the action of starting a timer automatic rather than manual;
e.g: a person drags a task "card" from the "Todo" to the "Doing" column or applies an in-progress labels will automatically start the timer on the task without requiring an additional click.

@iteles thoughts?

[iteles]

I use a timer app every day as a test and to be honest, I would say that I've started timers retrospectively every day for the last 5 weeks.

For me it's not so much about forgetting (maybe once a day after a long task) as it is about the various times in the day when I'm called to do something different at a moment's notice or when tasks meld into each other.

However, I probably only do it because I can. People should appreciate the discipline of getting that timer started and not having the option would help (me!) with that.

[iteles]

As this is now a 'key feature' rather than 'the most critical component' of the application, I would suggest that we default to having users start their own timers manually for now and then test having this started on the server.

My hypothesis is that for an individual, it would be enfuriating to not have control over this and ultimately, would lead to inaccurate data from people forgetting to start timers and then gradually not longer using the application because it's already exasperated them once.

If our target audience were organisations racking up billable hours, that would be a different story. But this is about building a tool for humans, which will enhance their days, not for their employers.

[nelsonic]

@iteles the question of this issue is relating to time differences between the device (client) and server
and preventing "time travelling" ...

[nelsonic]

This question was relevant in the old schema where we had a single timestamp for the start_time.
We no longer have that in the latest schema. Please see: #265