redarn redarn skrev:
Då bjuder på det missförståndet av mig och hämtar en till öl i stället för att leta fram rätt standard för certifikatvalidering.
Svaret är att enligt RFC 2459 är certifikatet giltigt under hela sekunden 1/1/2022 3:13:52 AM CET, men inte nästa sekund.
 
Redigerat:
useless useless skrev:
Svaret är att enligt RCF 2459 är certifikatet giltigt under hela sekunden 1/1/2022 3:13:52 AM CET, men inte nästa sekund.
Om vi säger RFC 2459 så tror jag dig! :p
 
När jag skriver kod som använde sig av tokens brukar jag dra av 5 sekunder av giltighetstiden för att vara säker på jag förnyar i god tid. Kan vara något sådant som spökar eller buggar i web filtret.
 
Alfredo Alfredo skrev:
Om vi säger RFC 2459 så tror jag dig! :p
Jaja.. "Request comments for 2459..."
 
AndersMalmgren AndersMalmgren skrev:
Kan vara något sådant som spökar eller buggar i web filtret.
Fast här handlar det inte om sekunder. Någon klocka som går fel är nog troligare.

Edit: Eller ja, det handlar om sekunder. Rätt många dock.
 
Alfredo Alfredo skrev:
Fast här handlar det inte om sekunder. Någon klocka som går fel är nog troligare.

Edit: Eller ja, det handlar om sekunder. Rätt många dock.
Tror på någon bugg snarare. då det började fungera nästan direkt. Klockan går på internettid dessutom
 
AndersMalmgren AndersMalmgren skrev:
Tror på någon bugg snarare. då det började fungera nästan direkt. Klockan går på internettid dessutom
Jag vet en stor myndighet som också litade på sin "internettid". Den var väldigt korrekt ändå tills den enda ntp-servern de pratade med råkade få tuppjuck...:thumbdown:
 
Alfredo Alfredo skrev:
Jag vet en stor myndighet som också litade på sin "internettid". Den var väldigt korrekt ändå tills den enda ntp-servern de pratade med råkade få tuppjuck...:thumbdown:
Single point of failure är aldrig bra. Men om du loggar tydligt så i detta fallet borde det räcka eftersom det tar rätt lång tid för klockan att desynca så mycket att det blir problem.

En annan rolig grej är hur många som har problem använda datum mellan tjänster. Man ska alltid använda UTC så man blir oberoende av lokala zoner. Men så är sällan fallet.
 
AndersMalmgren AndersMalmgren skrev:
det tar rätt lång tid för klockan att desynca så mycket att det blir problem.
Beror helt på hur det är konfigurerat. Och har man en enda ntp-server så är kanske inte heller övrig konfiguration optimal. ;)

Sen vad som är problem beror väl på. I det fall jag syftar på gick klockorna fel med dagar/månader/år. Minns inga detaljer men vi pratar jättefel. Tror dock inte att det egentligen medförde några "reella" problem.

Nej nog OT för mig nu.
 
AndersMalmgren AndersMalmgren skrev:
Single point of failure är aldrig bra. Men om du loggar tydligt så i detta fallet borde det räcka eftersom det tar rätt lång tid för klockan att desynca så mycket att det blir problem.

En annan rolig grej är hur många som har problem använda datum mellan tjänster. Man ska alltid använda UTC så man blir oberoende av lokala zoner. Men så är sällan fallet.
Om datum, månads, eller årsgränser är viktiga eller om det är nära presentation till användaren kan det vara fullt rimligt att använda lokal tidszon.

Det beror som så mycket annat vad man håller på med

"Ja lokalt skatteverk, i UTC-tid så hamnar fakturan i nästa period, så vi betalar skatten då"
 
Alfredo Alfredo skrev:
Beror helt på hur det är konfigurerat. Och har man en enda ntp-server så är kanske inte heller övrig konfiguration optimal. ;)

Sen vad som är problem beror väl på. I det fall jag syftar på gick klockorna fel med dagar/månader/år. Minns inga detaljer men vi pratar jättefel. Tror dock inte att det egentligen medförde några "reella" problem.

Nej nog OT för mig nu.

Jag har råkat ut för det för ett antal år sedan på den tiden RTC'n på moderkortet gick på batteri som tog slut efter några år. När datorn power-cyklades startade klockan på nåt bra värde från tidernas begynnelse (enligt hårdvarutillverkaren) och om inte NTP-servern kunde nås så tickade den glatt vidare från det datumet.
 
redarn redarn skrev:
Om datum, månads, eller årsgränser är viktiga eller om det är nära presentation till användaren kan det vara fullt rimligt att använda lokal tidszon.
Man presenterar alltid tid/datum enligt användarens valda tidszon och format. Men internt i systemet använder man UTC-tid om man vill slippa problem.
 
useless useless skrev:
Man presenterar alltid tid/datum enligt användarens valda tidszon och format. Men internt i systemet använder man UTC-tid om man vill slippa problem.
Nej.

Jag lovar att den mesta kod jag skriver använder lokal tidszon hela vägen för att det blir mycket enklare och begripligare.

Om du inte med "systemet" menar något mer specifikt.
 
redarn redarn skrev:
Om datum, månads, eller årsgränser är viktiga eller om det är nära presentation till användaren kan det vara fullt rimligt att använda lokal tidszon.

Det beror som så mycket annat vad man håller på med

"Ja lokalt skatteverk, i UTC-tid så hamnar fakturan i nästa period, så vi betalar skatten då"
Inte när man pratar mellan system. Lokalt i systemet får man göra om UTC till lokal tid. I UI presenterar man klientens tidzon. (Om man av någon anledning inte vill presentera någon annan tidszon)
 
AndersMalmgren AndersMalmgren skrev:
Inte när man pratar mellan system. Lokalt i systemet får man göra om UTC till lokal tid. I UI presenterar man klientens tidzon. (Om man av någon anledning inte vill presentera någon annan tidszon)
Ja då blir det oftast mycket mer praktiskt.

(inte alltid så klart, skatteverk vill inte sällan ha lokalt juridiskt korrekt datum, och då de ofta har makt att skicka uniformerade flickor och pojkar med batong och läderkoppel får man lov att lyda)
 
Vi vill skicka notiser för ämnen du bevakar och händelser som berör dig.