Davis stations have the habit of switching to DST. As if this wasn't bad enough, they don't know where they are; if they are in Greece they should be switching time at 03:00 (in the March) or at the first occurrence of 04:00 (in October); if in Germany, it should be one hour earlier than these times; and so on. But Davis stations, not knowing where they are, have the stunningly bad habit of always changing time at 02:00 (March) or at the first occurrence of 03:00 (October). Because of this, we had timezone=Europe/Berlin, because in loggertodb<3 timezone is only used to determine the moment of the DST switch.
However, in loggertodb>=3, the timezone is actually used to interpret the timestamps, so we necessarily need timezone=Europe/Athens. In the best case, some data near the time of the DST switch will have the wrong timestamp, which we will ignore. But I'm afraid that what will actually happen is that it will fail near the time of the DST switch. Or maybe it will fail only in October.
Davis stations have the habit of switching to DST. As if this wasn't bad enough, they don't know where they are; if they are in Greece they should be switching time at 03:00 (in the March) or at the first occurrence of 04:00 (in October); if in Germany, it should be one hour earlier than these times; and so on. But Davis stations, not knowing where they are, have the stunningly bad habit of always changing time at 02:00 (March) or at the first occurrence of 03:00 (October). Because of this, we had
timezone=Europe/Berlin
, because in loggertodb<3timezone
is only used to determine the moment of the DST switch.However, in loggertodb>=3, the
timezone
is actually used to interpret the timestamps, so we necessarily needtimezone=Europe/Athens
. In the best case, some data near the time of the DST switch will have the wrong timestamp, which we will ignore. But I'm afraid that what will actually happen is that it will fail near the time of the DST switch. Or maybe it will fail only in October.