If this is your container from GitHub I had no problem on oct.22, ~22:00 (CEST)
BUT:
- I run all docker just from the Win CMD line
- docker system prune  -f      to clean away all old junk
- docker-compose build       no extra flags
- docker-compose up -d        works as expected
- docker-compose logs         to verify the startup

Ah, that's something different.
You require a conversion table by location + a time range when DST is to be applied! 
Location is a static thing to be defined once.
DST is a real challenge as it depends on the region and requires annual adjustment by location.
Including the chance that Europe may split up next year or drop it at all.
It might make sense to get it from an external government source by country.
it is definitely not included in any InterSystems product.   

I see 2 principal ways:

  • using $ZDateTime(), $ZDateTimeH() function to convert your timestamp to Posix Format and then add or subtract whatever seconds offset you require, with the advantage to easily cross day boundaries
  • or to use system variable $ZTIMEZONE to adjust the timezone of your actual process independent of the system's time zone by any number of minutes

Nothing prevents you to have such rules as part of your object definition.
And all the code to define this is definitely part of Caché or IRIS.
Caché and IRIS have excellent SQL support and projection of objects to simple tables.

But you should not try to compare an Object database to any relational database.
Just as a comparison, you won't ask:
  Why does a 747 not have red blinking warning lights at his back like a yellow school bus?

In reverse the 2 you mentioned try to mimic features of an Object database. With limited success.