Times appear to be recorded in local timezone

[akaszynski]

When changing timezones the results from timetrace list records today do not change. Times should be recorded in UTC and displayed relative to the current timezone.

[dominikbraun]

Even though timetrace is still at v0.10.0, I'd like to maintain backwards-compatibility. So there are three options to switch to UTC:

• Leave everything as it is and convert record timestamps to UTC when computing durations and displaying those timespamps.
• Store everything in UTC in the future. When reading "legacy" records, detect whether they are UTC or not and convert them if necessary.
• Introduce a configuration value for using UTC and assume UTC or not depending on that configuration. Maybe implement a migration command for converting old records to the currently configured time format.

@aligator PTAL

[aligator]

I would say we should add an automatic conversion which is run the first time someone uses timetrace in the new version. (we can add something like a file with a version number somewhere in the .timetrace folder to indicate a new file-format.)

As I recently had a similar requirement at my daily work, I noticed some things to be aware of when using UTC in the "backend" and any localtime in the frontend:

• It is always better to save data in UTC to have no problem when changing the timezone. Worst case: each value saved is in a different timezone...
• different timezones may go through a daychange. So you have to adapt your loading logic to always also search for UTC-dates from the day before / after as e.g. if the client requests localtime today (with e.g. +2h timezone) you have to select for requested time (e.g. 0:00) -2h -> results in a requested time of yesterday 22:00 - today 22:00 UTC.
• -> you always have to check the folders of the day before and after for times which are today in localtime.
• -> when creating a converter from localtime to UTC, files may have to be moved to other record folders.

An additional suggestion: When we are anyway in process of changing the file format: Why don't we use a one-file database such as sqlite? It would have several benefits, such as

• only one file to read
• avoiding the issue of the other issue with the need to rename all files if the project name changes because then we can use a normal relational database design and do the rest through IDs
• would avoid the need to read several folders because of the timezone issue noted above. We could then just compose a proper sql select which selects the time-dates needed for the current timezone.

--> Actually this is no easy task but we should change the saved values to UTC.