Datum/Tijd van elkaar aftrekken fout ivm zomer/winter overgang

Hallo,

ik heb een probleem met queries icm zo-wi en wi-zo overgang. Ik moet datums van elkaar aftrekken (zelfde probleem ga ik ook nog krijgen met optellen), waarbij ik vervolgens het aantal minuten, of kwartieren of uren moet gaan berekenen tussen de 2 waarden. Voor "gewone dagen" gaat dit prima, maar bij overgangsdagen (zo->wi: laatste zondag van oktober en wi->zo: laatste zondag van maart) loopt het fout. Elke dag, dus ook de overgangsdagen, worden gezien als "normale" dagen van 24 uur.

De simpele formule VerschilInMinuten: Round(([dateuntil]-[datefrom])*24*60;0) geeft dus een fout resultaat.

Weet iemand een oplossing voor dit probleem? Hoe kan ik ervoor zorgen dat er wel rekening gehouden wordt met het extra uurtje in de lente en de uurtje minder in de herfst?

(en het subprobleem als de begindatum/tijd & de einddatum/tijd in het overgangsuur valt: kan er dan een extra vraag gesteld worden via de query of er een uur extra toegevoegd moet worden of niet)?

Een voor mij hele belangrijke voorwaarde voor de oplossing is dat de oplossing in de query wordt gerealiseerd, en dus niet via VBA code!

Ik hoop dat jullie me op weg kunnen helpen!

CoenEnAccess zei:

Een voor mij hele belangrijke voorwaarde voor de oplossing is dat de oplossing in de query wordt gerealiseerd, en dus niet via VBA code!

Klik om te vergroten...

Dan zullen weinig mensen je kunnen helpen vrees ik. Je laatste ‘eis’ (wel of niet meetellen op basis van gebruikersinput) kan denk ik niet zonder VBA.
Mij lijkt het logisch om de vraag niet te stellen, omdat de tijden nogal vastliggen. Je kúnt dus niet lukraak een uur wel of niet mee laten tellen. Als de eindtijd op 2 uur ligt, dan heb je gewoon de uren gewerkt. Zou je opmeennnormale dag een uur langer werken, dan is het 3 uur. Geen probleem. Met de overgang is het dan 4 uur, en trek je dus een uur af van het totaal. Lijkt mij allemaal nogal duidelijk.

Ik zou een extra tabel maken voor de wisseldagen en die als Cartesisch Product in je query opnemen. In die tabel neem je dan, naast de dagen, een numeriek veld op met de waarde +1 of -1. En daarmee corrigeer je de query. Als de twee datums vóór of ná de wisseldatum vallen, is er niks aan de hand en krijg je één record als output. In de overigeng3vallen krijg je drie regels, die bij elkaar dus ookmhet juiste totaal opleveren.

Dank je wel Octafish, ik ga hiermee aan de gang!

Ik zal zelf ook alvast een voorbeeldje in elkaar draaien voor het geval je er niet uitkomt .

Dat zou heel fijn zijn, mijn eerste poging is jammerlijk gefaald...

ff vraag: Het lijkt me dat je ook de tijd op moet nemen toch? Werken met een vanaf en een tot datum omdat volledig voor, of volledig na het tijdstip niets aan de hand is. Of los je dat niet op in de tabel, maar in de query?

In die tabel hoef je dat niet op te nemen, omdat d€ wissel tijden vastliggen. Tenzij je rekening wilt houden met toekomstige veranderingen.

Volgens mij werkt het

"Rekening houden met toekomstige veranderingen": ik hoop dat de enige toekomstige verandering afschaffing van die ellendige regel is

Volgens mij heb ik het concept werkend. Ik vraag me alleen af of dit de "netste" manier is, rekening houdend met de wens om het in 1 query op te lossen.
Ik heb in de tabel MarketDocument 2 rijen toegevoegd: DateFromRounded en DateUntilRounded. Beide velden zijn "berekend", met de formule Round([DateFrom];0) & Round([DateUntil];0)

Daarnaast een tabel aangemaakt met de naam Datum, bevattende: DatumId, Datum en Urensituatie (die laatste met de in te vullen waarden +1 en -1).

In de query 2 leftjoins waarin ik de zaken koppel.

Is dit de goede manier om verder uit te werken, of ga ik, als er een serieuze hoeveelheid data in gepompt wordt, tegen performance issues oid aanlopen?

Zal er zo naar kijken.

Ik heb er vandaag naar gekeken, maar je berekeningen zijn in mijn ogen niet correct. Dat kan ook niet, omdat je uitgaat van een datumomzetting die niet klopt: je gebruikt berekende velden die met Round werken, en dan krijg je verkeerde datums. En dus ook verkeerde uitkomsten. Ik zoek nog even naar een bruikbare methodiek, want het blijft natuurlijk een interessant probleem. Vooral voor de uren die je precies op het omslaguur afboekt.

Dank voor je reactie. Ik heb van een collega de tip gekregen om met UTC tijdsnotatie te werken. Volgens hem hoef je dan niet met een extra query te werken
22:00 - 22:00 in de zomer
22:00 - 23:00 op de overgangsdag
23:00 - 23:00 in de winter
23:00 - 22:00 op de overgangsdag.
Is misschien ook wel interessant om mee te werken.

Probleem dan is alleen hoe je de data in de formulieren kunt presenteren waarbij je de Nederlandse tijden wilt tonen.

Ik ga denk ik eerst inzetten in de extra query zoals jij voorstelt, voor mij is het wel van belang dat de gebruiker de nederlandse tijden ziet.

Interessant probleem indeed

Misschien kan je ook eens hier kijken https://www.helpmij.nl/forum/showth...l-omzetten-naar-Unix-met-zomer-en-winter-tijd
In dit draadje worden ook berekiningen met tijd gedaan gedurende winter- en zomertijd.
Het is welliswaar in excel maar ook in VBA, en je krijgt een idee van welke problemen kunnen spelen.

Dank Alphamax, ik ga het ff bestuderen. Met betrekking tot de queries wil ik dat het niet opgelost wordt met VBA code (zie eerste post), maar als het een "berekeningsonafhankelijke" overal toepasbare manier is, is het misschien wel interessant voor mijn probleem.

Ik vermoed dat het is op te lossen met DLookup. Ik heb 'm nog niet helemaal af, maar het ziet er veelbelovend uit. Wél is dus de manier waarop jij de hele dagen en uren berekent fout. In mijn voorbeeld klopt dat wél; ik gebruik namelijke DateSerial en TimeSerial. Kijk daar maar eens naar, voordat je verder gaat met Round .