Support for Daylight Saving Time (DST) transition

[dennissiemensma]

Coming sunday 27th of March is the first DST transition since I've started this project. I've used Django's timezone aware features, but I still have to check:

• Whether MySQL respects the transition. Or not.
• What will the DSMR meters do, will they actually apply DST or just keep going at the current rate? I expect they will respect the transition, as they are connected to the Internet anyway (using GPRS).

Since we will be skipping an hour, in the worst case all data of that hour will be lost. Next winter will be more interesting, as the hours drops backwards, potentially overriding existing data when not respecting timezones (MySQL).

[dennissiemensma]

Too bad that it seems to crash the datalogger. Honestly, I was expecting the backend to fail, not the datalogger. The meters are DST aware it seems, but I got no clue why the datalogger crashes.

[dennissiemensma]

 File "/home/dsmr/dsmr.git/dsmr_datalogger/management/commands/dsmr_datalogger.py", line 27, in run
    dsmr_datalogger.services.telegram_to_reading(data=telegram)
  File "/home/dsmr/dsmr.git/dsmr_datalogger/services.py", line 137, in telegram_to_reading
    value = reading_timestamp_to_datetime(string=value)
  File "/home/dsmr/dsmr.git/dsmr_datalogger/services.py", line 160, in reading_timestamp_to_datetime
    year=2000 + int(timestamp.group(1)),
AttributeError: 'NoneType' object has no attribute 'group'

[dennissiemensma]

Aah I see, the last character in the timestamp marks the DST period. I was wondering what the W was meant for. Now it's ending with a S, crashing my regex's.

[dennissiemensma]

Fixed in #105. More checks tomorrow, datalogger is the most important one..

[dennissiemensma]

For the next summer to winter transition I will have to signal pytz whether the input time is with or without DST, as the same hour is read twice. It wouldn't have been a problem when the meters used UTC as output, but apparently for some reason they choose not to do so.

[dennissiemensma]

Fixed it in the timestamp input reader, which now both manually sets DST to the W/S value and also returns the timestamp in UTC.

It already was timezone-aware, but Django formatted it to +1 or +2. PostgreSQL shouldn't care, as it already keeps track of tzinfo, but MySQL might be bugged by it.

[dennissiemensma]

Merged. Next winter's DST transition should be no problem.