klok zetten

Op 25 mei 2023 22:36:07 schreef Paulinha_B:
[...]

Als je me het mierenneuken niet kwalijk neemt: de oplossing heet NTP, op basis van o.a. GNSS-informatie zoals bv. Glonass, GPS, Galileo, ....

Ff terug ziften dan ..

Er zijn klokken die inderdaad GPS gesynced zijn ( en dat kun je ook prima zelf draaien met een GPS ontvanger aan een seriële poort oid, of een fabrieks doos met een ingebouwde NTP server )

Maar er hangen ook master klokken aan het net zonder de GPS tussenstap..

Deze bijvoorbeeld.

En wellicht ook de masters uit de startpost van dit topic.

Ja, zeker wel. Daarom ook de "o.a." in mijn eerdere bericht. En ook bij die ntp-servers aan hogescholen en universiteiten zullen er wel een aantal zijn die niet op satellieten voortgaan. Eigenlijk denk ik dat we het heel erg eens zijn

dat kun je ook prima zelf draaien met een GPS ontvanger aan een seriële poort oid

Ik doe het lekker met een Glonass-ontvanger, inderdaad aan een USB-poort met een ingebouwd rs232-usb omzettertje.

[Bericht gewijzigd door Paulinha_B op vrijdag 26 mei 2023 13:22:22 (31%)

Ha Kortsluiting_Online.

Op 25 mei 2023 18:34:49 schreef Kortsluiting_Online:
Ik ben nogal afgenkapt op die "atoom klokken".

Beweren ze allemaal dat die dingen beter dan 1s in 10.000 jaar zouden lopen, en dan blijkt dat na een jaar of 20 de Cesium ontsnapt (of zoiets) en het ding het helemaal niet meer doet, en ook vrijwel niet te repareren is.

Bah.

Dat is een goede

Groet,
Henk.

Op 26 maart 2023 16:08:44 schreef Sine:
[bijlage]

Ofwel .... eergisteren nog ophouden met die onzin.

Dan moet je ook eerlijk zijn en zeggen dat we voortaan overstappen naar UTC tijd en niet CET/MET. De scheiding CET/UTC ligt op 7,5° OL en dat is ongeveer ter hoogte van Koblenz (50.360023, 7.589907).

Wat hebben we er aan dat het rond de zonnewende om 2:39 licht wordt (civil twilight begin. nautical twilight begin is al om 1:28). Dat op mijn locatie in de buurt van Mechelen noordelijker nog vroeger. 99% van de bevolking ligt dan te knorren en de rest is meer dan waarschijnlijk aan het werk. Dat maakt dan ook dat om 20:01 de zon zal onder gaan. Einde civil twilight end om 20:46. Iemand die met ploegen werkt zal altijd in het duister thuis komen.

Consequentie is dan ook dat we weer met een uur verschil zitten met het oostelijke deel van de EU. Net zoals voor 16 mei 1940 toen ene Adolf Hitler CET invoerde in de bezette gebieden. Nederland had toen nog Amsterdamse tijd die 20 minuten voor was op UTC, eigenlijk zowat de meest correcte tijd voor België en NL. Bij de winter zonnewende zal de zon dan weer ondergaan, op mijn locatie, om 3:38. Noordelijk nog vroeger. Bijvoorbeeld Leeuwarden zal de zon onder gaan om 3:22.

Duitsland, Oostenrijk en Italië stappen sowieso niet mee in het verhaal. In Italië bestond CET+1 al in 1970.

Het bioritme gezever nemen we ook best met een korrel zout. 1 uur verschil 2 keer per jaar is blijkbaar problematisch en heel erg ongezond. Meerdere keren per jaar naar de andere zijde van de wereld nemen dezelfde personen er dan weer graag bij. In het weekend op café gaan of naar een feest tot 's morgens vroeg vinden dezelfde personen ook geen enkel probleem. Iemand die in 2 of 3 ploegen werkt doet wekelijks een switch van meerdere uren.

Vergeet het dat het snel zal opgelost worden. Duitsland en Oostenrijk zijn grote tegenstanders. Als het wijzigt zal het eerder richting vast UTC+2 zijn.

Daar is inderdaad heel wat aan te relativeren, en sommige mensen houden er inderdaad gewoontes op na die veel meer strijdig zijn met een natuurlijk tijdsbesef.
Zelf probeer ik zoveel mogelijk op te staan en te gaan slapen met de zon, al is dat lastig in de puttekes van womer en winter. En mijn klokken staan al jaren permanent op UTC.

Overigens is 7,5 graad oosterlengte enkel de theoretische grens CET/UTC, of beter gezegd tussen UTC+0 en UTC+1.

Hier in Portugal is het overigens in de winter UTC, in de zomer UTC+1. Tenminste in de winter lopen mijn klokken "gelijk" - maar met de zon lopen ze altijd redelijk gelijk. Alhoewel ik hier op meer dan 8 graden westerlengte zit, eigenlijk al in de UTC-1 ...

En ja, dat bioritme is wel degelijk een belangrijke factor, al zal de ene persoon er wel meer gevoelig aan zijn en een andere wat minder.

Nu, of we +1 of +2 of wat dan ook doen is minder relevant; maar twee keer per jaar omschakelen is inderdaad onzin, het kost alleen maar geld en ergernis.

Zelfs unix software kan er niet mee omgaan. In zo ongeveer alle implementaties zit een vette bug in het "date"commando.
Zelfs al 50 jaar.

Bijvoorbeeld: Bereken eens de epoch tijd van een datum?

Als je dat in de winter doet werkt het commando goed (geen DST dus).
Doe je dat in de zomer klopt het niet en zit je er naast.

Dat is, nu we in de zomertijd zitten, heel makkelijk te zien op een linux bakje of zo:

date -j +%s 197001010000

Uitleg:
-j Doe geen time set
+%s geef de epoch tijd in seconden weer.
197001010000 is "1 januari 1970 0h 0m 0s" dus het begin van het epoch.
Hier zou 0 uit moeten komen, maar werkt niet correct.

Try it out ik zeggen en post je bevindingen (met O/S versie?).

Try it out ik zeggen en post je bevindingen (met O/S versie?).

date -j +%s 197001010000
date: invalid option -- 'j'

Linux *** 5.15.0-72-generic #79-Ubuntu SMP Wed Apr 19 08:22:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

[Bericht gewijzigd door Boudie op vrijdag 26 mei 2023 18:48:09 (28%)

Ik had onder FreeBSD de -j nodig om te zorgen dat mijn klok niet gezet wordt. (Andere *BSD versies waarschijnlijk hetzelfde).
Waarschijnlijk -j even weglaten? Zal het even op een andere laptop met een linux VM testen.

In linux 4.15 en MINGW32_NT-10.0 etc:

date +%s -d 19700101

Op 26 mei 2023 12:51:52 schreef buckfast_beekeeper:
[...]

Vergeet het dat het snel zal opgelost worden. Duitsland en Oostenrijk zijn grote tegenstanders. Als het wijzigt zal het eerder richting vast UTC+2 zijn.

Dan doen die lekker hun eigen ding

Op 26 mei 2023 18:48:42 schreef henri62:
Ik had onder FreeBSD de -j nodig om te zorgen dat mijn klok niet gezet wordt. (Andere *BSD versies waarschijnlijk hetzelfde).
Waarschijnlijk -j even weglaten? Zal het even op een andere laptop met een linux VM testen.

In linux 4.15 en MINGW32_NT-10.0 etc:

code:

date +%s -d 19700101

Bij mij:
date +%s -d 19700101
-3600

Ja, dat is wel een apart resultaat...
Er is natuurlijk wel een mooi verhaal bij te bedenken, maar kloppen doet 't inderdaad niet.

En alles wordt zo simpel en zo netjes als men gewoon in UTC werkt:

karel@wiske:/ date +%s -d 19700101
0
karel@wiske:/ date
Sat May 27 08:28:30 UTC 2023

Op 26 mei 2023 19:30:41 schreef Sine:
[...]

Dan doen die lekker hun eigen ding

Gaat ook niet gebeuren tenzij NL voor een NEXIT kiest en zijn eigen ding gaat doen.

Op 27 mei 2023 10:30:26 schreef Paulinha_B:
En alles wordt zo simpel en zo netjes als men gewoon in UTC werkt:

[...]

Krijg je er ook nooit door. De directe en indirecte kostprijs daarvan gaat niemand willen ophoesten.

Pfff. Ik zet mijn klokken toch zoals ik wil? Wat is er daaraan "door te krijgen"?

Op 27 mei 2023 10:24:45 schreef Boudie:
[...]

Bij mij:
date +%s -d 19700101
-3600

Ja, dat is wel een apart resultaat...
Er is natuurlijk wel een mooi verhaal bij te bedenken, maar kloppen doet 't inderdaad niet.

Als je dit in de winter intyped dan klopt het wel. Hier wordt dus altijd domweg 1uur eraf getrokken. Alle unixen zijn "broken" wat dit betreft.

Niks zo dramatisch als datum en tijd calculaties. Ik heb er al enorm veel tijd aan verbrand om dat overal in allerlei projecten goed te krijgen en om de meest stompzinnige bugs heen te werken.

[Bericht gewijzigd door henri62 op zaterdag 27 mei 2023 16:20:39 (19%)

Op 26 mei 2023 18:24:30 schreef henri62:
Zelfs unix software kan er niet mee omgaan. In zo ongeveer alle implementaties zit een vette bug in het "date"commando.
Zelfs al 50 jaar.

Het zal wel "op een manier" correct zijn. Misschien ben jij het er niet mee eens, maar als het er nog steeds in zit, dan zal het wel volgens de definitie zijn van hoe het hoort.

assurancetourix:~> date +%s -d '19700101 MET'
-3600
assurancetourix:~> date +%s -d '19700101 UTC'
0
assurancetourix:~> date +%s -d '19700101 MEST'
-7200
assurancetourix:~> 

Ik denk dat dit de bedoeling is.

Die gasten die Unix-hoe-het-hoort (SUS?) handleidingen geschreven hebben die hebben ook een paar fouten gemaakt. Een aantal dingen zijn gewoon ERG onhandig in de praktijk. Stel ik "grep" naar een string in een text-file. Maar door een onhandigheid zit er halverwege het bestand een "raar" karakterteken. Ik krijg dan verschillende resultaten als mijn zoek-string VOOR of NA halverwege zit.

assurancetourix:~> ( seq 10000 49999 ; echo '\0' ; seq 50000 99999 ) > test.txt
assurancetourix:~> grep 12345 test.txt
12345
assurancetourix:~> grep 72345 test.txt
grep: test.txt: binary file matches
assurancetourix:~> 

En, daar kom ik zojuist achter, het gedrag hangt af van hoe groot het file is. Toen ik het met drie cijfers (100-999) deed, gaf ie ook "binary file..." toen ik naar 300 zocht. En het hangt af van welk "raar" teken je er in zet: mijn eerste drie pogingen vond ie best.

Dit is toch niet "handig" gedrag voor een tool die je in een script wil gebruiken? Bij het testen zet je 100000 regels in je bestand en het werkt altijd. En na deployment verdwaalt er een u-umlaut in je bestand en bingo, het werkt niet meer! (dus ook als eenmalig die umlaut in je bestand sluipt: het werkt ineens nooit meer voor de data daarachter (en soms d'r voor)).

De jongens die "grep" maken zeggen: Voorgeschreven door SUS.

grep is sowieso niet meer van de tijd. awk is wat lastiger om te leren maar werkt wel veel konsekwenter en bovenal een pak sneller.
grep gebruik ik nog juist af en toe voor een vluggertje vanaf de command line, in scripts enkel nog awk.

Overigens werkt uw test bij mij wel hoor, Linux 4.15:

karel@wiske:/tmp$ grep 12345 test.txt
12345
karel@wiske:/tmp$ grep 72345 test.txt
72345
karel@wiske:/tmp$ awk '/72345/' test.txt
72345

karel@wiske:/tmp$ grep --version
grep (GNU grep) 3.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others, see <http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.

[Bericht gewijzigd door Paulinha_B op zondag 28 mei 2023 09:34:32 (58%)

Ik heb op mijn standaard machine grep 3.7 uit 2021. Ik heb ondertussen op 1 machine versie 3.1 zoals de jouwe gevonden. Doet het zoals ik het beschreven heb. Ik heb een machine gevonden met grep 2.27. Gedraagt zich ook al zoals ik beschreven heb.

OK. Gevonden waar het aan ligt. Ik gebruik tcsh. De echo '\0'resulteert dan in een echte NUL byte in het file. Als je bash gebruikt komt er 0x5c 0x30, een backslash en een ascii nul in het testbestand te staan. Ik weet even niet hoe ik dat in bash moet intikken.

Voor bash gebruikers is het maken van het testfile:

 ( seq 10000 49999 ; dd if=/dev/zero bs=1 count=1; seq 50000 99999 ) > test.txt

dit werkt ook voor (t)csh gebruikers zoals ik.

Ik heb de boel bij VSL nog opgebouwd en jaren beheerd.
Was leuk om te doen. Als ik nog laat in de avond bezig was, belde mijn vrouw met weet je wel hoe laat het is?.

Groeten,
Erik (een andere)

Als ik nog laat in de avond bezig was, belde mijn vrouw met weet je wel hoe laat het is?

Wahaha, goeie!

[Bericht gewijzigd door Paulinha_B op vrijdag 2 juni 2023 19:06:05 (90%)

Op 2 juni 2023 18:47:43 schreef Discord:
Ik heb de boel bij VSL nog opgebouwd en jaren beheerd.
Was leuk om te doen. Als ik nog laat in de avond bezig was, belde mijn vrouw met weet je wel hoe laat het is?.

Groeten,
Erik (een andere)

Ben jij dat op de foto ?

Ja dat ben ik. Zit ook nog in een klokhuis uitzending.
Die was ook leuk om te doen. Die heette 'De tijd'

Erik