Okay, I'll try to be more specific.gizmocuz wrote:The major problem is the short-log
We need to store these in UTC
the daily log we (of course) store in localtime, according the users timezone
When we request the short-log data, we (of course) convert them to localtime
There will be no graph issues
UTC does not change with a change of seasons, but local time or civil time may change if a time zone jurisdiction observes daylight saving time or summer time.
We do not need to change any datatables, only the datetime stamps of the short logs, and of course all queries, but thats not difficult
The thing is: I looked at the code. What you call short-log I presume to be table [MultiMeter] for the P1 meter and this table is maintained by a timed event that takes data from the current device status. At present that function does not load any timestamp associated with that data into the table, but leaves it to SQLight to generate a timestamp value according to a rule that is part of the table properties.
Of course, the application can still provide any other valid datetime string to overrule the automatic assigned value, but at present the table properties state to enter localtime if the client omits that value.
Which by itself is not a problem. The values are still good. The trouble arises with how these values are processed. Since we have double time values when moving away from DST we get a sort issue. With the times currently stored as localtime this results in a list of values like this:
Code: Select all
... 01:50 01:55 02:00 02:00 02:05 02:05 02:10 02:10 02:15 02:15 02:20 ...
If we store times as UTC we do not get the sort issue, but if we convert to localtime that will still give us the double time values but in a different order:
Code: Select all
... 02:45 02:50 02:55 02:00 02:05 02:10 02:15 ...
Either way there are graph issues, unless we export UTC values (with or without a fixed offset) to the client. When using localtime our options are: mixing, superimposing, or skipping/hiding.