Bag timezone #233
Bag timezone #233
Conversation
In de BAG database stonden de tijdvelden zonder een tijdzone. Dat is met deze commit aangepast. Standaard wordt de tijdzone 'Europe/ Amsterdam' gebruikt. Dat betekent GMT+1 of GMT+2 (zomertijd). Postgres is zelf slim genoeg om die omzetting te kunnen maken. Niet getest met Oracle.
|
Eens met de schema wijzigingen. Het aanpassen van de ISO-string in BAGAttribuut heeft mijn voorkeur: met De ISO string aanpassen in BAGAttribuut L340 is m.i. eenvoudigweg:
Dan wordt aangegeven: deze tijd is in UTC+1 (staat los van zomer/wintertijd m.i.). Maar goed idd gaat het meer om de datum, hoewel tijd 00:00:00 meestal is en daardoor in sommige gevallen de datum kan worden veranderd als uitgegaan wordt van UTC. Blijft lastig onderwerp! |
Nee,
Ja, aan zo'n oplossing had ik ook gedacht, maar volgens mij stap je dan te snel over het zomer/wintertijd-probleem heen. De 'Nederlandse tijd' is soms UTC+1 en soms UTC+2.
Inderdaad, sterker nog: volgens mij wordt de tijd hier enkel gebruikt om een volgorde aan te geven, niet zo zeer specifieke tijden.
Tijdzone, zomertijd, wintertijd: altijd een gedoe, zeker als je de wereld wilt overnemen. |
|
Denk ook om dat als je de tijd veranderd met een tijdzone offset je de kans loopt een record over de dag heen te tillen. |
|
On 22-01-18 22:04, Rob van Loon wrote:
Het aanpassen van de ISO-string in BAGAttribuut heeft mijn voorkeur:
met self.uitvoeren("SET time zone '%s'" % tijdzone) zet je toch de
tijdzone voor de hele database? Dat kan voor sommigen wat onbedoelde
effecten hebben en weet niet of daar altijd permissies voor zijn
(kan mogelijk van gebruiker/role afhangen).
Nee, |SET time zone| stelt alleen de time zone voor de /sessie/, niet
voor de hele database. Zie de postgresql documentatie
<https://www.postgresql.org/docs/9.3/static/sql-set.html>. Daarmee zou
het redelijk veilig moeten zijn.
Natuurlijk, was even in de war met de ALTER DATABASE SET TIME ZONE
variant. Per sessie is ok, dan wordt de SQL self._waarde = '%s-%s-%s
%s:%s:%s.%s' neem ik aan als Europe/Amsterdam geinterpreteerd.
self._waarde = '%s-%s-%s %s:%s:%s.%s UTC+1' % (jaar, maand, dag,
uur, minuut, seconden, secfract).
Dan wordt aangegeven: deze tijd is in UTC+1 (staat los van
zomer/wintertijd m.i.).
Ja, aan zo'n oplossing had ik ook gedacht, maar volgens mij stap je dan
te snel over het zomer/wintertijd-probleem heen. De 'Nederlandse tijd'
is soms UTC+1 en soms UTC+2.
Ja, klopt ook, uiteraard is UTC+1 niet DST bestendig! Alleen
Europe/Amsterdam is DST bestendig.
Maar goed idd gaat het meer om de datum, hoewel tijd 00:00:00
meestal is en daardoor in sommige gevallen de datum kan worden
veranderd als uitgegaan wordt van UTC.
Inderdaad, sterker nog: volgens mij wordt de tijd hier enkel gebruikt om
een volgorde aan te geven, niet zo zeer specifieke tijden.
Blijft lastig onderwerp!
Tijdzone, zomertijd, wintertijd: altijd een gedoe, zeker als je de
wereld wilt overnemen <https://xkcd.com/1883/>.
Leuke strip, ja komt in ieder project weer terug, bijv
smartemission/smartemission#38
|
bag/src/postgresdb.py
Outdated
| @@ -57,6 +57,7 @@ def verbind(self, initdb=False): | |||
| self.maak_schema() | |||
|
|
|||
| self.zet_schema() | |||
| self.zet_tijdzone(); | |||
There was a problem hiding this comment.
hier staat nog overbodige ;
|
alleen de |
|
Aaarghh! Dat is wel erg stom. Hij is weg nu. |
Deeloplossing voor issue #223 (alleen BAG)
Bij het inlezen van de BAG-gegevens wordt de tijdzone ingesteld op 'Europe/Amsterdam' en hiermee worden alle data van die tijdzone voorzien. Dit gaat er dus vanuit dat de BAG-gegevens altijd in die tijdzone zijn opgesteld, maar dat lijkt me een redelijke aanname. Consequentie is dat voor wintertijd UTC+1 en voor zomertijd UTC+2 wordt gehanteerd.
Alternatieve oplossing is de ISO-string bij het inlezen (zie BAGdatetimeAttribuut ) aan te passen naar een tijdzone, maar dat geeft wat meer code-gedoe, terwijl postgres het eenvoudig kan oplossen.
Overigens geeft het tijdstip meer een "volgorde in de dag" aan dan een specifieke tijd (zie pagina 8 van BAG koppelvlak.