( … tijdsstempel … )
WELKE tijd neem je ?
bv. linux : werkt met GMT - UTC als timestamp
bv. M$-windhoos : werkt met lokale tijd als timestamp
Misschien ook ergens een bron van ellende ?!?
UTC is ook wel bekend als Z of Zulu-tijd.
Windows intern gebruikt de “Admirality clock” epoch = 1 jan 1601, in de UTC zone.
Alle frontend interacties zijn lokaal, vergelijkbaar met Unix, Linux etc.
RFC: RFC 4791: Calendaring Extensions to WebDAV (CalDAV)
DTSTAMP is een required deel van een VEVENT/VCALENDAR object. Dus elk object op een server moet een timestamp hebben.
Slakken/Zout/… ok.
GMT, CET, etc. zijn ook geen tijdzones, maar tijdstippen. met een variatie t.o.v. UTC.
En het gebied waar het betreffende tijdstip gebruikt wordt is de tijdzone… Voor de EU +GB is dat met name CET/CEST
GMT=~UTC+00:00, CET=UTC+01:00 CEST=UTC+02:00 etc.etc.
En net als in UTC is CET overal op de wereld ook gelijk…, het is de locale tijd die veranderd.
De lokale (zonne, natuurlijke) tijd wordt vastgesteld door te meten wanneer de zon op het hoogste punt staat, dat is lokaal exact 12:00 (definitie).
Het zijn met name de spoorwegen geweest die de oorzaak waren van tijdzones omdat een verschil in tijden tussen oost en west van een land erg onhandig uitpakken met lokale tijd verschillen. voor een eenvoudige spoorboekje was zonering van tijdstippen handiger.
UTC+01:00 is de natuurlijke/zonne tijd voor iets voorbij Berlijn (Frankfurt am Oder). (~15 graden OL)
UTC+02:00 is de natuurlijke/zonne tijd voor richting Kiev. (~30 graden OL)
Nederland zit (gemiddeld) eigenlijk meer natuurlijke tijd op UTC+00:20 (~5 graden OL tussen 3.3 =UTC+00:13 en 7.2 =UTC+00:29)
In het spraakgebruik wordt er dus gesproken over tijdzones UTC, CET, CEST, WET, etc als het uitwerkings gebied waar het betreffende tijdstip van toepassing is.
En epoch is variabel, afhankelijk van het nul punt dat je zoekt
Windows-epoch = 1 jan 1601, 00:00 UTC met 100 ns step (128 bit, signed) [ Britse Admiraliteit , start GMT]
OpenVMS epoch = 17 November 1858 00:00 UTC met 100 ns step (128 bit, signed) [ Smithsonian = Julian Day 2400000.5, sterrekundige tijd wissel ]
Unix / Linux epoch = 1 januari 1970 00:00 UTC, met 1 sec. step. (32bits signed)
Bijbelse epoch , Julian day 0 [ scheppings verhaal ]
Christelijke Epoch , variabele tijdstap enkele malen bijgesteld, jaar 0 [ Geboorte Christus ]
Chinese Epoch, Islam Epoch etc laat ik als oefening voor de lezer.
Omdat tijd zones een politiek gevalletje zijn kun je onderstaande source ophalen
https://data.iana.org/time-zones/releases/tzdb-2022c.tar.lz van Time Zone Database
in de tzs file erin staat per tijdzone van wanneer tot wanneer een tijdzone actief was en welke verschuiving van toepassing is t.o.v. UTC
Deze file wordt jaarlijks diverse malen herzien, dit is de 3e versie voor 2022 (dit omdat sommige landen/staten nog altijd “@ random” de tijd wissel tussen zomer en wintertijd instellen, en deze soms enkele weken voor de daadwerkelijke instelling publiceren).
De Linux timezone data wordt uit deze file samengesteld.
https://hemel.waarnemen.com/applets/utrechtsetijd.html
De zonnetijd is behoorlijk variabel.
Als ik in Japan een klok op CET zet (= UTC+01:00) dan volgt die klok nog steeds precies UTC +01:00…
en is daarmee een tijdstip. Dat de klok geen Japanse tijd weergeeft doet er niets aan af.
Kijk ook even naar de ~ tekens… ik heb niet de locaties met EXACTE coordinaten gegeven, maar bekende objecten m.b.t de tijd en hoe WIJ die natuurlijk ervaren (Zonnetijd lokale tijd…)
CET wat wij normaal wintertijd vinden Central European tijd, komt overeen met de Zonnetijd van nabij Frankfurt am Oder.
CEST wat wij normaal zomertijd vinden is Central European Summer Time komt overeen met de Zonnetijd vlak (iets ten westen) bij Kiev.
Zonnetijd is de tijd die “variabel” is door schommelingen in de aardbol.
Tegenwoordig is CET gedefin bij Kievieerd als UTC +01:00 en CEST als UTC+02:00 en zijn dus net zoals UTC een tijdstip. (ongeacht waar op de wereld je deze tijd op een klok instelt).
Het uitwerkingsgebied is in EU afspraken vastgesteld in de EU… (en heeft dus een wat grillige oost en west grens, niet de nette meridianen. Het is de gekozen tijdsaanduiding in dat werkingsgebied… en dat uitwerkingsgebied is de tijdzone.
De keuze van de klok stand in het uitwerkingsgebied, is die van de lokale overheid. Ondanks dat de correcte lokale tijdstippen voor Nederland (Cadzand bad ~ UTC+00:13 en Delfzijl ~ UTC+00:27) kiezen we er toch voor om de klok van de lokale (ongeveer zonnetijd) tijd van FrankFurt am Oder te voeren in de winter en in de Zomer kiezen we voor de Ukrainse lokale natuurlijke tijd. (Dat schijnt beter voor de handel oid te zijn).
Als het beter was voor de handel en we hadden vrijwel exclusief met Japan gehandeld dan hadden we hier in NL gewoon Tokio lokale tijd op de klok gezet.
Natuurlijke lokale tijd is de tijd waarbij de Zon op het hoogste punt staat precies op het midden van de dag. (en dat kan en zal iets afwijken een met atoomklokken gemeten tijd…, maar biologie, natuurkunde etc werkt op de Zonnetijd … niet op klok tijd.
Sommige onderdelen van de natuurkunde werken op atoomklokken tijd. (het schijnsel Schrikkel seconde, Schrikkel dag… is ook om Zonnetijd weer een beetje in de buurt van een absolute standaard als UTC te krijgen en houden).
Mijn zonnepanelen werken van Zonsopgang tot Zonsondergang… (nou iets korter). niet van UTC tijdstip X tot UTC tijdstip Y waarbij X en Y een constante zijn bv. 08:00 (CET) tot 19:00 (CET)
Kippen worden wakker met zonsopgang…, niet als de klok 14:00 Tokyo tijd weergeeft (elke dag).
Ik laat het hier verder bij.