Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamp with timezone in postgres #223

Closed
arjennienhuis opened this issue Jul 31, 2017 · 9 comments
Closed

Timestamp with timezone in postgres #223

arjennienhuis opened this issue Jul 31, 2017 · 9 comments

Comments

@arjennienhuis
Copy link

Volgens mij is van alle tijden de tijdzone bekend. Dan zouden de kolommen timestamptz moeten zijn. Ze zijn nu allemaal timestamp zonder timezone.

In postgres is een timestamp zonder timezone een soort geometry zonder srid.

@fsteggink
Copy link
Member

fsteggink commented Oct 4, 2017

Goed punt. Dit is i.i.g. bij de BGT en BAG zo. Bij de BRK en TOP10NL laten we trouwens de tijden als string staan. Dat moet beter kunnen. Dit heeft er ondermeer mee te maken dat GDAL/OGR moeite heeft (had?) met het omzetten van datum- en timestamp-velden in de GML naar velden van het juiste type in PostgreSQL. Bij de BAG wordt trouwens geen gebruik gemaakt van GDAL/OGR.

@borrob
Copy link
Contributor

borrob commented Jan 19, 2018

Voor het BAG heb ik de wijzigingen klaar staan. Vraag: de tabeldefinities veranderen (van zonder naar mét time zone), moet de schema-versie dan ook opgehoogd worden ? @fsteggink

VALUES ('schema_versie', '1.1.1');

@justb4
Copy link
Contributor

justb4 commented Jan 20, 2018

@borrob Bedankt! Ja hoog schema-versie maar op. Idd, timestamptz heeft voorkeur. Belangrijker, hoewel in BAG datums belangrijker zijn dan uren, minuten, is hoe bij inlezen de juiste conversies worden gedaan. Geen idee eigenlijk hoe in de BAG bijv begindatumtijdvakgeldigheid qua tijdzone is. In ieder geval wordt bij inlezen een ISO 8601 string gevormd, maar zonder TZ, bijv 1999-01-08 04:05:06.78. Doe je daar ook iets mee? Je kan anders wel een PR aanmaken voor code review.

@borrob
Copy link
Contributor

borrob commented Jan 20, 2018

Thanx. Ik open zo een pull request. Ik heb aangenomen dat de aangeleverde gegevens in de Nederlandse tijdzone (Europe/Amsterdam) zijn gebeurd. Bij het inlezen wordt de db-connectie op die tijdzone ingesteld en daarmee krijgen de datumtijd-velden dat automatisch toebedeeld bij het inlezen. Dat betekent UTC+1 voor wintertijd en UTC+2 voor zomertijd.

Overigens begrijp ik uit pagina 8 van de beschrijving van het BAG-koppelvlak dat:

Tijdvakgeldigheid wordt op diverse plekken hergebruikt. Het gaat hier in principe om datums. Het type lijkt echter op een datum-tijd, maar moet geïnterpreteerd worden als een datum. Het tijd-deel van de datum is om meerdere voorkomens op één dag uniek van elkaar te kunnen onderscheiden. Dit moet geïnterpreteerd worden als een volgnummer binnen de dag. De hoogste c.q. laatste is degene die telt bij een bevraging op deze dag (actueel of peildatum).

Hieruit haal ik dat het dus niet zo zeer om een specifieke tijd gaat, maar meer om een volgorde. Ik zal kijken wat ik nog voor de BGT en de andere datasets kan doen.

@borrob borrob mentioned this issue Jan 20, 2018
@fsteggink fsteggink self-assigned this Jan 28, 2018
@fsteggink
Copy link
Member

Issue aan mezelf toegevoegd, om dit voor de TOP10- en overige BRT-extracten en BRK-extract na te kijken / fixen.

@borrob
Copy link
Contributor

borrob commented Feb 16, 2018

Vanwege de discussie op #238 realiseer ik me dat LOCALTIMESTAMP in de actueel-views (NLExtract/bag/db/script/bag-view-actueel-bestaand.sql) nog aangepast moet worden naar now(). Het lijkt me goed om de discussie in die draad eerst af te wachten of er wél of geen tijdzones gehanteerd gaan worden voordat we eventueel extra werk moeten terugdraaien.

@fsteggink
Copy link
Member

@borrob: Just en ik hebben beide besloten om je aanpassing intact te laten, dus mocht je in de gelegenheid zijn om hiervoor nog een PR te maken, dan zou dat heel fijn zijn.
Ik ga nu aan de slag met de andere hierboven genoemde extracten. Eindelijk tijd 🎉

@fsteggink
Copy link
Member

Voor de BRK zie PR #242 .

@fsteggink
Copy link
Member

De BRT-features hebben alleen datums. TOP50NL en TOP100NL bevatten wel data met tijdstippen, nl. objectbegintijd en objecteindtijd. Het laatste attribuut is altijd leeg, omdat de BRT alleen actuele data bevat. Bij objectbegintijd is het tijdstip altijd 00:00:00.000. Dat is logisch, want bij TOP10NL is helemaal geen tijdstip meerbeschikbaar en dit lijkt een gevolg van een verouderd datamodel. Zie ook de versienummers. TOP50 en 100 zitten op v1.1 en de rest op v1.2.

Ik ga het issue afsluiten, want in alle datasets waar dit van toepassing is, hebben we een tijdzone toegevoegd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants