Timestamps of readings no longer correctly displayed (offset by 1 or 2 hours)

[JeanMiK]

I have recently upgraded my two dsmr-reader instances running under docker from 4.8 to 4.12. At the same time, I also updated the PostrgeSql docker to a newer version (now postgres:12.6 as current version of tag postgres:12; upgrade by docker pull of the initial postgres:12-alpine corrupted the db which would no longer start). After quite a lot of trouble linked to the db server upgrade and the issue #1299 (which I solved in the same way as the author of the issue by updating locally libseccomp2), I finally got the two readers running again, but I now notice that the timestamps displayed in the GUI are incorrect:

In the latest telegram, I have e.g. at 17:38 local time received
0-0:1.0.0(210218173818W)
which means that the meter sends correct information (Feb 18 2021 at 17:38:18 winter time)

In the database, the timestamp is stored correctly with the configured timezone Europe/Amsterdam, meaning that in dsmr_datalogger_dsmrreading.timestamp, I can see the value "2021-02-18 17:38:18+01", which is the correct timezone "+1" for winter time.

But in the admin page admin/dsmr_datalogger/meterstatistics/ of the GUI, the value in the "Timestamp" field below the telegram shows an offset of 1 hour, i.e. "Feb. 18, 2021, 6:38 p.m.", and in the live graph, the newest data points are even shown with a time of "19:38", i.e. an offset of 2 hours.

In the dashboard, the time of the most recent telegram is just shown as 'now' (where before, I used to see something like '7 seconds ago'), and in the page statistics of the GUI, the time of the meter position is shown as "59 minutes from now"

I did not see anything in the change log or the installation notes that would explain this behaviour,

In the docker-compose.yml, I still have the environment variable parameters TZ=Europe/Amsterdam and PG_TZ=Europe/Amsterdam for the db docker, and DJANGO_TIME_ZONE=Europe/Amsterdam for the two reader dockers, which was working fine with the prevuous version 4.7

[dennissiemensma]

Did you happen to notice #1282? It might be related to your situation due to future times, but I'm not sure.

[dennissiemensma]

By the way. Note the solution linked in that issue description. You might want to change to 12.4-alpine. Both non-alpine and newer alpine versions did not seem to work.

[JeanMiK]

It seems indeed to be linked to the same underlying problems. I did not see #1282 myself, as it was already closed by the time I had my issues.

The update of the postgres:12-alpine docker container did also 'kill' my db ( like @Tralapo, I had a segmentation fault on start-up of the db), which triggered me to switch to postrge:12 for the db.

The time shift is similar, and it seems to be caused by django in the GUI parts. I am not using the remote data-logger, but the integrated one, and as I said, the timestamps in the db look correct with timezone "+1".

I now reverted back to postgres:12.4-alpine, and that one does indeed neither crash nor present the time shift.

It does not solve the underlying problem, as the newer postgres-alpine versions are not working at all right now (not even with an empty db for me), but it is at least a workaround.

There is a fair chance that combining a postgres:12 with a python3:slim as base image for the reader would work as well. Maybe @xirixiz can try this. At the very least, you should both put big, fat warnings in the change logs of the reader itself and the dockerized versions, as we are at least two now who got their db screwed up by the automatic pull of postrge:12.6-alpine .

[8uurg]

I've posted some instructions (though in Dutch, hopefully not an issue!) on how to get the newer alpine images to work under #1282 (comment).

[JeanMiK]

I had already updated libseccomp2, but I was under the impression that it was only needed to get python / django to work with the new postgres:12 docker, not for the functionality of the server itself.
Indeed postgres:12 (i.e. postgres:12.6) seemed to have been working fine in stand-alone mode with the recovered db even before I did the libseccomp2 update, it was only the reader itself that showed me error on the Time initialisations.
Do you think that this library was then also responsible for the newer postgres:12-alpine containers to not even start with an empty db?

[8uurg]

Do you think that this library was then also responsible for the newer postgres:12-alpine containers to not even start with an empty db?

After updating libseccomp2 I can boot postgres:12-alpine which crashed with a segmentation fault previously. So I do think that this library was responsible for that as well.

[dennissiemensma]

For other users, see #1282