freddie wrote: ↑Sun 01 Aug 2021 6:45 am
If it was my design, then internally I would use a fixed time zone with no DST and convert on-the-fly when making the data available externally.
That has been suggested many times in this support forum over the years.
Of course, in response, Steve Loft's Cumulus 2 was coded to do just that, using UTC internally, and in log files, just converting to local time zone on outputs.
Steve apparently found it impossible to make it work, I don't recall him explaining why he struggled with the UTC to local time conversions. Perhaps it was because of the complications for rollover processing time or because his C# skills were limited?
Anyway, he abandoned that idea when his MX beta took some ideas from both Cumulus 1 and Cumulus 2.
I have an idea that Mark has, at times, considered making MX incompatible with the legacy by various internal standardisations (with external presentational conversions) to make coding easier. In my opinion MX has already diverged so much from the legacy, I don't think compatibility between them matters any more, especially as it is possible to write one-off conversion utilities.
freddie wrote: ↑Sun 01 Aug 2021 6:45 am
Something I've been doing for years. When storing and manipulating timeline-based data such as meteorological readings then artificial adjustments such as DST have no place in the storage layer.
I am sure I recall several other Cumulus users in the past, not just you, saying they had adopted a fixed time-zone, either for easier comparison with official data or because they have an international interest in their weather data.