Feedback from Byron (Umbrella)

[simonsan]

Summary:

• Data Storage and Safety:

  • Clarify data storage mechanism on project page; prefer real database like SQLite for data safety.

• Data Import:

  • Support for importing existing data; consider providing importers for different sources (pace import -t clockify times.csv).

• Data Export:

  • Ensure easy export of all data, preferably with SQLite backend, to avoid user lock-in.

• HTML Templating for Reports:

  • Include HTML templating engine for generating reports or summaries for invoices.

• Testing:

  • Implement comprehensive tests, including journey tests and unit tests, ensuring accuracy in timesheets and invoices. Verify behaviour with timezone switching.

• Cross-Platform and Syncing:

  • Initial support on single machine is acceptable, but future consideration for multi-device sync and web interaction would be valuable. Self-hosting option preferred, but potential for productization exists if done well.

Originally posted by @Byron in Byron/byron#4 (comment)

[simonsan]

Considering Timezones

1. Switch internal time representation to chrono::Utc for consistency.
2. Implement input time conversion to UTC before storage.
3. Convert UTC times to user's local time zone for display.
4. Handle time zone switches gracefully by adjusting durations and display times accordingly. (e.g., when a task started in one time zone and ended in another)
5. Investigate usage of chrono-tz for complex time zone rules.
6. Add user-configurable time zone options in application settings.

[Byron]

Thanks for setting up this issue, much appreciated!

Regarding timezones: I really like the proposal as I think it will work. One test I can think of is:

• user starts task in timezone A
• maybe more than a day passes
• user ends task in timezone B

Something I also wonder about is if it would be good to store the timezone as well, just like Git does. That would allow the times to look natural, no matter from which timezone they are looked at. Think about me being in China for half a month, and in Germany another half. By the end of the month, I generate a timesheet for an invoice. If I am in Germany when doing it, it will look like I worked at night while logging time in China which isn't accurate. Clients might rightfully say that they are afraid of the quality produced by someone with insomnia ;).

So to catch this case, I think the timezone would also have to be stored to be able to store the local time of each task, with the possibility that start and stop are in different timezones.

[simonsan]

@Byron I'm sitting on it, but I need some better understanding from the user experience side and I would appreciate your help and ideas for this:

I want to do it in the way, that normally, people don't need to deal at all with timezone shenanigans.

1. So as a first measurement, I will store a default timezone in the configuration file, which you can choose in the setup assistant that already exists with pace setup config. For us, this would be Europe/Berlin. I will further get the local offset from UTC and “guess” the countries you can decide from based on the offset in seconds to use these in the setup assistant's fuzzy select as higher priority, so they will appear closer to the cursor.

2. As a second measurement, I'll introduce an optional command-line option to set the timezone or an offset from UTC for beginning and ending an activity. So that people have full control over it, even if they set something in their config. I imagine it like:

# short
alias tt = pace
tt b "My activity" -c "development::pace" -tzo +1
# -tzo should not be needed here, as that should be able to be determined
# automatically, but we should probably make it possible, to overwrite it

# or a bit longer
pace begin "My activity" -c "development::pace" -tz Europe/Berlin
pace begin "My activity" -c "development::pace" --tz-offset +1

3. For the third measurement, the storage, I'm a bit unsure still. If we don't store the actual full time zone string, we lose out on information, which could be useful in the end. But as this is optional, and we cannot always determine it, it needs to be optional. The fallback will always be the automatically calculated tz-offset from local time.

Any feedback, if I have forgotten/overlooked anything for usability?

[Byron]

Happily!

(it took me moment to realise, but I think instead of 'measurement' it should be 'measure')

Regarding 1), I really like the idea of a fuzzy & smart country selector to nail the current timezone. I think it should be made clear that this setting only affects changes done after timezone change (even if it means to stop a timer in a new timezone, like would be the case in a cross-country flight).

Regarding 2), even though a short-form like +1 seems reasonable, internally it should store no less than what git stores for a timezone, i.e. sign + hours and minutes. The Europe/Berlin example indicates that this form at least would already allow that.

• Regarding 3), and like already mentioned in 2), it should be enough to store sign + hours + minutes to capture a timezone precisely enough. No timezone will just default to +0000 (like Git would see it).

Personally I see great benefit in storing dates the Git way, and somehow I consider it a solved problem especially if one wants to lean into what Git already provides. Of course, I have a Git bias, but recommend taking a look at gix-actor for producing and parsing timestamps.

As long as the timezone is stored per timestamp, and an event as start and end times, I think the data model should be fine for this case (and that's what I vaguely remember to being the case already).