Timestamps processed in the future

[jellekpsn]

Setup/Architecture information

Docker Container on raspberry pi 4. Datalogger on esp8266 based wemo sending data through network socket.

Version of the Docker image

DSMR-reader v4.11

Configuration

  dsmrdb:
    image: postgres:12
    restart: always
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./volumes/dsrm/dsmrdb:/var/lib/postgresql/data
    environment:
      - TZ=Europe/Amsterdam
      - PG_TZ=Europe/Amsterdam
      - POSTGRES_USER=dsmrreader
      - POSTGRES_PASSWORD=dsmrreader
      - POSTGRES_DB=dsmrreader

  dsmr:
    image: xirixiz/dsmr-reader-docker:latest
    depends_on:
      - dsmrdb
    cap_add:
      - NET_ADMIN
    restart: always
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./volumes/dsrm/dsmr_backups:/dsmr/backups
    environment:
      - DJANGO_TIME_ZONE=Europe/Amsterdam
      - VIRTUAL_HOST=localhost
      - DATALOGGER_INPUT_METHOD=ipv4
      - DATALOGGER_NETWORK_HOST=192.168.2.249
      - DATALOGGER_NETWORK_PORT=8088
      - DATALOGGER_DEBUG_LOGGING=1
    ports:
      - 7777:80
      - 7779:443

Describe the bug

I'm running the container since yesterday any everything seems to be working fine except for 1 thing.
The timestamps are processed to be 1 hour in the future. Even more confusingly, the live graph is set 2 hours in the future.
The telegram timestamp seem correct but is then processed to be 1 hour in the future. Any ideas what could be the underlying cause? Thanks for the awesome software and help!

Debug log

DSMR-READER
    App / Python / Database                                                       v4.11 / v3.9.1 / postgresql
    BE sleep / DL sleep / Retention / Override                                    1.0s / 2.0s / 2016h / False
    Latest telegram version read / Parser settings                                                 "50" / "4"

DATA
    Telegrams total (est.)                                                                              15558
    Consumption records electricity / gas (est.)                                                  15079 / 168

UNRESOLVED ISSUES
    No day statistics found                                                                               now

Latest Telegram received at 14.48 my local time (Amsterdam).

/ISK5\2M550E-1012

1-3:0.2.8(50)
0-0:1.0.0(210218144832W)
0-0:96.1.1(4530303439303037343733373039383139)
1-0:1.8.1(000788.374*kWh)
1-0:1.8.2(000959.221*kWh)
1-0:2.8.1(000000.000*kWh)
1-0:2.8.2(000000.000*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(00.348*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00008)
0-0:96.7.9(00002)
1-0:99.97.0(1)(0-0:96.7.19)(190902152638S)(0000000600*s)
1-0:32.32.0(00009)
1-0:32.36.0(00001)
0-0:96.13.0()
1-0:32.7.0(229.1*V)
1-0:31.7.0(001*A)
1-0:21.7.0(00.349*kW)
1-0:22.7.0(00.000*kW)
0-1:24.1.0(003)
0-1:96.1.0(4730303634303032303036353834303230)
0-1:24.2.1(210218144501W)(00972.154*m3)
!A430

Screenshot where you can see the discrepancy.

[ferensw]

If you remove the localtime dir volumes, the timestamps presumably will be correct.
I did not have figured out why or why these are needed....

[mhvis]

I just encountered the same issue. Removing the volume bind /etc/localtime:/etc/localtime:ro from both containers, as suggested by @ferensw, fixed it for me.

[jellekpsn]

Can confirm it worked. Closing.