Open justb4 opened 2 years ago
Lijkt me wel, begindatumtijdvakgeldigheid, etc. is ook een timestamp with time zone
NLExtract zou geen timestamp with time zone
moeten gebruiken, zoals het in het verleden ook niet deed (#238).
Mijn setup heeft changes daarvoor.
Strikt genomen zou extract_datum()
gecast moet worden naar DATE
omdat het geen tijdscomponent heeft.
Als ik issue #238 teruglees, zijn we daar toentertijd niet uitgekomen en zijn er ook geen wijzigingen geweest. Echter, ondertussen zijn we overgeschakeld op de BAG 2.0 en de LV-BAG driver gebruikt wel timestamp with time zone
voor deze velden, dus deze keus is voor anderen door ons gemaakt.
Verder klopt het dat de extract datum geen tijd is, maar een datum. Maar hoe bepaal je dan wat er op bijv. 8 januari de actuele stand is, als er wijzigingen zijn met begin-/einddatum (timestamps) die in de loop van 8 januari zijn geregistreerd? Middernacht (00:00:00), midden op de dag (12:00:00), 1 seconde vlak voor middernacht (23:59:59) of iets anders? We zullen hiervoor een keus moeten maken. Bij een vergelijking tussen een date en een timestamp cast PostgreSQL de datum naar het tijdstip 00:00:00
, dus middernacht, maar dat hoeft niet de intentie te zijn van de standdatum in de BAG.
Echter, ondertussen zijn we overgeschakeld op de BAG 2.0 en de LV-BAG driver gebruikt wel timestamp with time zone voor deze velden, dus deze keus is voor anderen door ons gemaakt.
De LVBAG driver in GDAL gebruikt date
voor begingeldigheid
& eindgeldigheid
kolommen, het gebruikt timestamp with time zone
voor de tijdstip kolommen (tijdstipregistratie
, eindregistratie
, tijdstipinactief
, tijdstipregistratielv
, tijdstipeindregistratielv
, tijdstipinactieflv
, tijdstipnietbaglv
).
Door bagv2/etl/sql/finalize-tables.sql
worden de kolommen voor bepaalde tabellen aangepast, e.g.:
ALTER TABLE nummeraanduiding ALTER COLUMN begingeldigheid TYPE timestamp without time zone;
ALTER TABLE nummeraanduiding ALTER COLUMN eindgeldigheid TYPE timestamp without time zone;
Deze BAGv1 compat wordt niet gebruikt in mijn setup, het vereist te veel extra disk space, en m.i. zou NLExtract zo dicht mogelijk bij de structuur van de BAG XML moeten zitten, wat de BAGLV driver ook doet.
(Vraag van extract dump gebruiker die historische selecties maakt).
De functie
extract_datum()
geeft eentimestamp without time zone
terug, maar wordt meestal vergeleken met eentimestamp with time zone
. Is het niet beter en robuuster omextract_datum()
dan ook eentimestamp with time zone
terug te laten geven?