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
Okay, I'll try to be more specific.
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 ...
This is in fact how the graph drawing library likes to receive the X-axis values. So that's good. We just don't handle this situation very well and end up with crazy numbers. This is not very hard to fix, except for the 02:00 value that follows 02:55 which we cannot reference at that point.
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 ...
This is NOT how the graph drawing library likes to receive the X-axis values and it will generate a warning (see post @11/02/2016 11:25) , but it will fix our crazy numbers without further code change.
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.