Ivan-Johnson
commented
4 years ago Actually, I think that having a separate table is the clear winner. Simply consider the logistics of not having timezone information be a separate entry.
Where is that information determined? e.g. a smart scale wants to POST a new weight entry. It seems like a hassle for the scale to have to keep track of the local timezone. If it's not the scale that determines the timezone but the server instead, wouldn't that in and of itself necessitate a timezone table?
If there's no separate timezone table, then changing historical timezone information is an expensive operation. More important is the fact that the code would have to be relatively complicated to handle edge cases relating to changed timezones. e.g. the user realizes that they forgot to update their timezone from TZA to TZB a few days ago and does so. Now a smart scale tries to post new information; how does it know to use TZB instead of TZA? It obviously shouldn't just use the timezone it had when it last connected to the server, but it can't just use the "latest" timezone either, as entries its posting might be sufficiently old that TZA is the correct timezone.
Currently, entries are simply tracked in absolute time as the number of seconds since the unix epoch. The typical competitor to LifeLog would at least have a single timezone associated with the user so that times can be formatted in their current timezone. However, users sometimes change their timezones. It would be better to have some way of knowing what timezone the user was in at the time of each entry.
One could directly store the timezone along with each entry in the database, but I think that's sub optimal. I think it would be better to have a table tracking each time that the user changes timezones. The obvious benefit is that this would reduce storage requirements, but LifeLog's present scale, that's negligible. Development costs are the key issue.
Having a separate timezone table will necessitate having more complicated code for fetching the timezone information associated with a set of entries, but it will simplify other code that doesn't depend on timezones.