Hány az óra, vekker úr?

 ( NevemTeve | 2018. június 22., péntek - 10:42 )

Ugye ez nem száz százalékban jó:

$ date -d "1941-04-07 23:59:59" +%s  -906771601
$ date -d "1941-04-08 00:00:00" +%s  date: invalid date '1941-04-08 00:00:00'
$ date -d "1941-04-08 00:59:59" +%s  date: invalid date '1941-04-08 00:59:59'
$ date -d "1941-04-08 01:00:00" +%s  -906771600

Vagyis a derék szoftver szerint a tavaszi előrecsavarás miatt 23:59:59 után másnap 01:00:00 következett. Namostan ha nekem egy 'csak dátum' mezőm van, akkor azt általában 00:00:00 időponttal szoktuk teljes dátum+idővé alakítani, ami a (legalábbis ezen a gépemen) "nem létezett". Speciel a wiki nem ezt írja, de persze az sem jogforrás...

Ha jól látom, a date(1) a /usr/share/zoneinfo/Europe/Budapest nevű fájlból tájékozódik; ez vagy a 'tzdata' csomagból került oda, vagy én telepítettem Olson-adatbázis egy frissebb változatát. Most mindenesetre apt-get-el frissítettem erre: tzdata-2018e-0+deb8u1, a fájl dátuma is nőtt, a date(1) kimenete változatlan.

20180623.1326 CEST Köszönöm a hozzászólásokat, sok hasznos gondolat van bennük, például, hogy jó lenne, ha nem kellene a 'dátum' és 'időpont' típusokat' keverni.
Sajnos a gyakorlat nem mindig ennyire egyszerű, itt van pl. az Oracle: van neki egy DATE tipusa, ami időpontot tárol (másodpercig), ha csak dátumot adunk meg, akkor az idő-rész nulla lesz. A DST-s problémát akár Sql*Plus-ban is elő lehet adni:

SQL> select sys_extract_utc (cast (date'1941-04-08' as timestamp)) from dual;
ORA-01878: specified field not found in datetime or interval

SQL> select sys_extract_utc (cast (date'1941-04-09' as timestamp)) from dual;
19410408.220000.000000                            

20180625.0720 CEST
Vagy itt van a Unix/libc időpont alapú dátumkezelés, ideértve a date(1) programot. Ha ezeket használjuk, a dátum-manipulációt időpont manipulációval lehet megvalósítani, de persze az időzónák és óracsavarások bekavarhatnak; pl ha az a kérdés, hogy 28202 nappal ezelőtt mi volt (-d '-28202 days'), akkor ilyesmi lehet a válasz:

now             nowutc          then           thenutc
20180625.005821 20180624.225821 19410407.235821 19410407.225821
20180625.005921 20180624.225921 19410407.235921 19410407.225921
20180625.010021 20180624.230021 19410408.010021 19410407.230021
20180625.010121 20180624.230121 19410408.010121 19410407.230121

Tehát ha az a kérdés, hogy 'ma 2018-06-25 van, mi volt a dátum 28202 nappal ezelőtt, időponttól és időzónától függetlenül [1941-04-08]', akkor nem is annyira nyilvánvaló, hogy ez a program hogyan használható erre. Most hirtelen ezt csaptam össze:

Now="$(date +%Y%m%d)"
Then="$(date --utc +%Y%m%d -d "$Now UTC -28202 days")"
echo "$Now" "$Then"

20180625 19410408

20180625.1251 Off: a zoneinfo fájlok nézegetése közben találtam egy elnevezést/jelölést, amit eddig nem ismertem: 'wall clock time' vs 'local standard time', az előbbi az aktuális helyi idő (nálunk most UTC+02:00, télen UTC+01:00), az utóbbi a helyi 'szokásos' (vagyis 'téli') idő. Hogy melyikről van szó, azt az időpont mögé tett betű jelöli: semmi=wall-clock, s=standard, z/g/u=utc. Tehát a legközelebbi óracsavarás előtt ennyi lesz nálunk:
2018-10-28 02:59:59 = 2018-10-28 01:59:59s = 2018-10-28 00:59:59u
utána:
2018-10-28 02:00:00 = 2018-10-28 02:00:00s = 2018-10-28 01:00:00u

20180717.1445 Még egy példa, Perlben: https://stackoverflow.com/questions/51351699/manipulate-date-in-unix/51378917#51378917

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

" Namostan ha nekem egy 'csak dátum' mezőm van, akkor azt általában 00:00:00 időponttal szoktuk teljes dátum+idővé alakítani"
Hát, olyan helyeken, ahol nincs figyelembe véve a normális időkezelés, ott így is van.
De lehet ezt szépen is csinálni, nem véletlenül létezik a Java API-ban erre megoldás:
jshell> import java.time.*;

jshell> ZonedDateTime time = LocalDate.of(1941, 4, 8).atStartOfDay(ZoneId.of("Europe/Budapest"));
time ==> 1941-04-08T01:00+02:00[Europe/Budapest]

Voilá.

A falsehoods cikksorozat időre vonatkozó részét érdemes itt említeni:
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
https://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time

Szerk: a wikinél egy kicsit hitelesebb a Magyar Nemzeti Levéltár cikke a témában:
http://mnl.gov.hu/mnl/ol/hirek/a_nyari_idoszamitas_magyarorszagon_1916_1945
Ez hivatkozik a 2650/1941 ME. rendeletre, amelyet a Hungricana-n megtalálsz:
https://library.hungaricana.hu/hu/view/OGYK_RT_1941/?pg=1205&layout=s&query=2.650.%20
"A m. kir. minisztérium a nyári időszámítás bevezetéséről szóló 950/1941. M. E. számra rendeletét (Rt. 1941. 136. o.) a következőképen) módosítja:
Magyarország területén a jelenleg használatos egységes középeurópai időszámítás, a 950/1941. M. E. számú rendelettől eltérően, 1941. évi április hó 8. napjától kezdődően akként módosul, hogy az új időszámítás a jelenlegit egy órával (60 perccel) megelőzi. Ehhez képest az 1941. évii április hó 8. napja — ,az egységes
középeurópai időszámításban kifejezve — már 1941. évi április hó 7. napján 23 órakor kezdődik."
Szóval a wiki pontatlan.

A falsehoods cikk jópár sorát lehet használni interjúkon is kérdésként.
Pld. adjon több lehetséges magyarázatot is erre a jelenségre:
"One minute on the system clock has exactly the same duration as one minute on any other clock"

Köszönöm szépen, sok hasznos információ van a hozzászólásodban!

A végső következtetésem valószínűleg az lesz, hogy az időpont nélküli dátumokat ('születés napja', rendelet kelte', 'közügyektől eltiltás lejárata'), ha egyáltalán dátumként kell kezelni, (például hozzá kell adni 30 napot, vagy levonni három évet), akkor UTC-ként érdemes felfogni. (Persze mindkét konverziónál, a string->adat, adat->string iránynál.)

Szerk: Például azért is, mert azt én nem tudhatom most, hogy a programot majdan futtató felhasználó gépén (vagy pláne a program által elért adatbázison) a TZ értéke Europe/Budapest lesz-e, vagy CET-1CEST-2,M3.5.0/2,M10.5.0/3 vagy esetleg gyáridefault/úgyfelejtettem

Persze, _mindent_ UTC-ként érdemes kezelni. Kivéve amit nem :-).

Pont ha hozzá kell adni 30 napot, az 30 naptári nap. Például ha 30 napod van befizetni a büntit, mert utána emelkedik a tét, akkor azt úgy kell értni, hogy hiába kaptad meg 15:37 perckor, attól még a 30. nap éfjéljéig tudod befizetni. Sőt, a 30. nap bankzárásáig. Vagy a posta zárásáig. Vagy a 29. nap zárásázig. Vagy esetleg a 31.nap zárásáig. Szóval érted. Végig kell ezt gondolni. Nehéz volt dönteni, de... döntöttem.

ESR mit mond, mikor kell helyi dátumot használni: http://esr.ibiblio.org/?p=7041

http://esr.ibiblio.org/?p=7901

Így van. Az időpont nélküli dátumokat úgy kell kezelni, ahogy vannak: időpont nélküli dátumként. És ezekhez az adatokhoz amit hozzá lehet adni: x napot, y hónapot meg z évet. De nem lehet hozzáadni ilyen dátumokhoz x órát, y percet, z másodpercet, mert annak nincs jelentése.

Nagyon fontos az adatmodellezésnél, számításnál, hogy dátumot, vagy időpontot kell tárolni, a kettő baromira nem ekvivalens, és csak nagyon nyakatekert konverzió létezik a dátum -> időpont irányba, sőt, van, amikor nem is tud ilyen leképezés konzisztensen létezni.

Van, amit nem tudsz UTC-re képezlni egyértelműen, konzisztensen. Például a te problémád pont ilyen: 1941. 04. 08 az egy dátum, ezt nem tudod UTC-re képezni. UTC-re időpontot tudsz képezni, és nem dátumot. A dátum az egy adott napot ad meg, de nem ad meg napon belül olyan időadatot, amivel ez egy időpont lenne.

Amúgy alap szerintem: adátum tárolása ISO-8601 szabványban leírt Gergely-naptár szerint, azaz ez egy nap felbontású sorozat. Hozzá tudsz adni napokat, hónapokat, éveket. Viszont itt időzóna tárolásának nincs értelme, hiszen nem tudsz órákat meg perceket meg másodperceket hozzáadni egy nap felbontású dátumhoz. A nap felbontású dátumok ezért mindig
"helyi dátumok", azaz két földrajzilag távoli pont között nem tudsz dátumokat értelmesen, konzisztensen összehasonlítani.

A másik meg az időpont tárolása: ez pedig hasonlóképpen az ISO-8601 szabványban leírt módon. Itt már tárolhatsz időzónát, hiszen ez egy adott időpontot ír le, egy naptári napon belül is. Itt amit érdemes csinálni: amit eltárolsz az egy fix időzóna szerinti időpont. Mindegy, hogy ez az időzóna mi, csak amikor számolni kell, akkor figyelembe kell venni, hogy a tárolt idők mely idózónában értelmezendők. A legkézenfekvőbb UTC-ben tárolni.
Amikor számolni kell vele, akkor tudsz hozzáadni x órát, y percet stb, és bármely földrajzi hely időzónája szerint megjeleníteni a helyi időt.
Így, mivel tárolva van kellő felbontású adat, ezért lehetőséged van arra, hogy két, földrajzilag távol álló pont közötti időpontokat összehasonlíts.

Ezen a ponton nem értek veled egyet. Pont az az UTC előnye, hogy konzisztens, nincs az, hogy időzónázni vagy DST-zni kell, meg ilyen 1941-ben egy óra ugrálások vannak barlangigazgatósági császári rendeletek alapján. Minden időpont érvényes benne visszamenőleg is, nincs inkonzisztencia. A végeredményt meg mindenki konvertálgatja belőle olyan időzónára és dátumra, amilyet a felhasználás kíván. Pont emiatt találták ki, nem csak azért van az UTC, hogy valami új buzzworddel lehessen szivatni a publikumot. Ahogy a kolléga is idézte itt egy lentebbi szálban, UTC ought to be enough for anybody. Külön pirospont, hogy 640 KB-ba is belefér :D


No keyboard detected... Press F1 to run the SETUP

"Minden időpont érvényes benne visszamenőleg is, nincs inkonzisztencia."
Ez sajnos nem igaz, lásd a szökőmásodperceket.
Lehet olyan UTC időpont, ami kimarad , amikor negatív szökőmásodperc van. Ilyenre még nem volt példa, de a szabvány megengedi.

Innentől kezdve az UTC sem jobb ám másnál, csak épp az az előnye megvan, hogy standardizált a jelentése (amely megvan a tzdata adatbázis más időzónáinál is). De attól még ugyanúgy nyilván kell tartani az alapvetően nem reguláris időközönként fellépő szökőmásodperceket is, mint minden más időzónánál a DST-t és hasonló változásokat.

Amint egy olyan libraryvel számolsz, ami figyelembe veszi ezeket, onnantól kezdve tök mindegy, melyik időzóna szerint tárolod az időket, csak legyél konzisztens.

Vannak olyan időmérési standardek, amiknél ilyen nincs (TAI, meg UT0/UT1), de ezeknek általában nincs szoftveres támogatása, mivel nem kapcsolódnak humán időkhöz (aka wall clockhoz) önmagukban. Az UTC az egy UT-> wall clock mapping tulajdonképpen.

Elvileg igazad van, gyakorlatilag viszont a legtöbb esetben semmi probléma nincs, ha a szökőmásodpercekkel egyszerűen nem számolunk :-).

Aham, ja:
https://www.theregister.co.uk/2012/07/02/leap_second_crashes_airlines/

Magam is szívtam meg ezt, pont ezt a szökőmásodpercet. Másnap reggel munkakezdéskor heves telefonálások, hogy nem működnek bizonyos alkalmazások, van, ami busy waitel, égeti a CPU-t stb.
Ők is azt gondolták, hogy a legtöbb esetben nem gond, ha nem vesszük figyelembe - persze, mivel ritkán történik meg. Viszont amikor megtörténik, akkor figyelembe kell venni :)

Ezt valahogy nem tudom elképzelni. Mármint hogy a szökőmásodperc hogy tud gondot okozni. Főleg, hogy az NTP-s megoldások ilyenkor nem hirtelen 2 mp-et ugranak 1 helyett, hanem csak felgyorsítják egy kicsit az órát, de az alkalmazásnak ezt úgy kell látnia, hogy telnek egyesével a másodpercek. Amelyik proginak ez gondot okoz, az gányul van megírva.

Annyi pontatlanság meg belefér, ha visszamegyünk egy XY múltbeli UTC dátumra, akkor a szökőmásodperceket nem számoljuk. Annyi szökőmásodperc még nem gyűlt össze a történelemben, hogy akár csak egy óra csúszást is okozzon, nem hogy egy egész napot.


No keyboard detected... Press F1 to run the SETUP

"Annyi pontatlanság meg belefér, ha visszamegyünk egy XY múltbeli UTC dátumra, akkor a szökőmásodperceket nem számoljuk. "
Nem teljesen.
Például hogyan mész vissza erről az időpontról egy évet?
2016-12-31T23:59:60+00:00 - ez egy létező időpont.
Mert ugye mondhatnád, hogy laza, legyen ez 2015-12-31T23:59:60+00:00
Ennek nincs értelme, ez az időpont egész egyszerűen nem létezett.

Mondhatnád, hogy "az előző év ugyanezen időpontja legyen az, hogy kivonok 365*24*60*60 másodpercet és ujjé", de ez ugye nem veszi figyelembe a szökőnapokat, meg a DST-t.
Baromira nem triviális probléma ez, hogy ha általánosan akarod kezelni.
Például: hogyan alkotsz meg egy olyan időtartamot, amely 2016 elejétől 2016 végéig tart?

Vagy kérdezhetnéd, hogy "hány másodperc telt el 2011-ban?"
Erre mi a válasz?
Az, hogy pontatlan a kérdés. Ugyanis Szamoán például 2011 egy kerek nappal rövidebb volt, december 30-át kihagyták (csütörtök után szombat jött), mert időzónát váltottak.

Meg kellene értened, hogy a szökőmásodperc pont ugyanaz a probléma, mint a DST vagy bármi más nem szabályszerű változás a szépen, egyenletesen folyó időszámításban (a relativisztikus hatásoktól most tekintsünk el).
Mellékesen megjegyzem, hogy a szökőév is pontosan ilyen dolog, csak épp arra van képlet, míg az időzónaváltásokra meg a szökőmásodpercekre nincs, azok nem regulárisak, így adattáblázat/adatbázis (ami a tzdata) kell hozzá, hogy leírja a változást.

Ha eljusz ide, hogy ezt felismerd, hogy normálisan kezelni időt csak normális szoftveres libraryvel lehet, és ne, ne akarj magadnak időkezelőt írni, akkor utána már mindegy, hogy UTC-ben, vagy Europe/Budapestben tartod nyilván az időt. Csak légy konzizstens, hogy miben.

A példáid valóban érdekesek, ezekre nem gondoltam, de a gyakorlatban, mikor visszamegyünk egy korábbi dátumra, akkor általában napokat megyünk vissza, nem másodperceket. Pl. ezt a unix epoch időt is ezért tartottam mindig is hülyeségnek.

Azt nem állítottam, hogy ezt nem kell kezelni, meg saját libraryt kell írni. Mindig is amondó voltam, hogy a beépített szabványos libeket, API-kat kell használni ilyen tekintetben, nem egyedi megoldásokat gányolni. Ne meg mindenek felett, UTC-t kell használni konzisztensen.

A szökőmásodpercnél felvetettem már egy időszámításos topikban, hogy hiába eseti jelleggel adogatják hozzá a szökőmásodperceket, be kéne vezetni egy képletezhető rendszert, amelyiknél ha hozzá is van adva, akkor kiszámíthatóbb helyen. Már így is korlátozzák, hogy csak jún. 30-án és dec. 31-én lehet hozzáadni éjfélkor, de kéne valami ennél is szigorúbb rendszer.


No keyboard detected... Press F1 to run the SETUP

"hiába eseti jelleggel adogatják hozzá a szökőmásodperceket, be kéne vezetni egy képletezhető rendszert, "
Ezt a Földnek is megmondtad?
Az időmérés során kétféle időt használunk, az egyik az, amit a fizikai folyamatok alapján jól definiáltunk, és másodpercekben mérünk. Ezt atomórákkal kiválóan tudjuk nagyon nagy pontossággal mérni (az időt tudjuk a legnagyobb pontossággal mérni az alapegységek közül). Ez az időmérés kiválóan alkalmas az eltelt idő mérésére (elapsed time). Ezt méri a TAI (temps atomique international), azaz angolul az International Atomic Time. Ez az SI másodperceket használja időmérésre.

Azonban mi emberek vagyunk, és az időt nem elapsed time-ként számoljuk csak, létezik számunkra a Föld forgásából adódó wall time is. A Föld saját tengely körüli forgását vesszük figyelembe, amikor dátumokat használunk, meg bevezetjük az óra, meg nap, meg perc fogalmakat. Erre használjuk az Universal Time nevű standardet, amely csillagászati megfigyeléseken alapul, távoli kvazárok és hasonló objektumok megfigyelésével. Ez a mérés valójában a Föld forgását méri, mivel mi emberek a Föld forgásához igazítottuk az időszámításunkat. A Föld forgása azonban csak megközelítően egyenletes, valójában sok tényező befolyásolja (és amúgy is, folyamatosan lassul a Hold árapályhatása miatt).
Ezt méri az UT1 idő. Azonban mivel a Föld forgása nem fejezhető ki egész számú SI másodperccel, egy nap valójában nem 86400 SI másodpercig tart.

Na, e kettő időmérési standardból jön az UTC időszámítás. Az UTC időszámítás ütemének alapja a fizikailag jól definiált és pontosan mért TAI - 1 UTC másodperc időtartalma az pontosan 1 SI másodperc, azonban ha csak ezt vennénk figyelembe, akkor bizony a Föld forgásától elmásznánk. Emiatt az UTC nem folytonsan telik, időnként 1-1 SI másodpercet tesznek hozzá, vagy vesznek el belőle a szabvány szerint, hogy az UT1 idő és az UTC idő között 0.9 SI másodpercen belül legyen a különbség.

Ez a módszer teljesen analóg ahhoz, hogy a Föld forgása és keringése nincs szinkronban.
Mivel nem 365 egész darab tengely körüli forgást csinál a Föld, miközben egyszer körbeér a Nap körül, ezért ha csak a fordulatok egész számú többszörösével számolnánk az éveket, akkor nagyot tévedne a naptár - ezért vezetjük be a szökőnapok fogalmát. Azonban a Gergely-naptár is tévedni fog majd egy teljes napot, csak az még nem jött el a bevezetése óta, ezért használunk rá szabályszerűséget, amikor a szökőnapokat használjuk.

A szökőmásodperccel pontosan ez történik: mivel nem 86400 egész darab SI másodperc telik el a Föld egy tengely körüli forgása során, ezért időről-időre módosítani kell a tengely körüli forgáson alapuló UTC időt.

Viszont itt szigorú szabály alapú rendszert nem nagyon tudsz adni, ugyanis az UT1 eléggé ingadozik, nem olyan egyenletes, mint a Föld keringése és forgása közötti kapcsolat, lásd:
https://en.wikipedia.org/wiki/DUT1
Szépen látszanak is a szökőmásodpercek.

Igen, ez mind világos. De! Attól, hogy próbáljuk a mesterséges (atomórás, elapsed time) időt hozzáigazítani a csillagászatihoz (Föld forgása), attól még be lehet vezetni egy szigorúbb, kiszámíthatóbb rendszert. Világos, hogy ezeket a szökőmásodperceket akkor toldják be, amikor szükséges, de mondjuk ha szigorítunk a rendszeren, akkor csak annyi változik, hogy nem toldhatják be szabadon, hanem néha várniuk kell egy képletezésre alkalmas slotra. Addig nem lesz tragédia, ha a kétféle idő között van 1 mp, a világnak nem lesz vége. Attól ezek épp úgy betoldódádnak végül. De még egy olyan rendszert is el tudnék képzelni, amikor ezeket a szökőmásodperceket nem adogatjuk hozzá, hanem egy elég könnyen megjegyezhető kerek dátumon ugrunk egy percet, mikor összejött egy percnyi ilyen másodperc. Jelenleg, a 46 évvel ezelőtti bevezetése óta mindössze 27 ilyen másodperc jött össsze. A lényege pont az lenne, hogy mivel nem egyenletes jelenségről van szó, ezért egyfajta szigorúbb rendszerrel tompítunk a szabálytalansásán egy olyan korrekciós mértékig, amikor még a kettő közötti eltérés elenyésző gyakorlati szempontból.


No keyboard detected... Press F1 to run the SETUP

Eh, kicsit naiv hozzaallas, es a gyakorlati tapasztalat hianyat mutatja. En emlekszem arra, amikor egy szokomasodpercnek koszonhetoen a linux kernel timerei ragadtak be... csupan par tizezer gepen kellett date paranccsal varazsolni, es az erintett penzugyi rendszereknel nagyon nem volt mindegy, mekkora ido alatt csokken ujra tizedmasodperc ala az offset olyan rendszereknel, amelyek tul nagy idoelteresnel lazan eldobjak a "regi" tranzakciokat. Kisse mas pelda a linuxos neverwinter nights, ami futo NTP mellett szeretett leakadni. Sok fejleszto eleteben nem hallott arrol, mire jo a CLOCK_MONOTONIC timer.

Mi miatt akadtak be a timerek, és miért kellett az offsetet csökkenteni egyáltalán?

Lehet, hogy naív vagyok, de úgy képzelem ezt, hogy az 1970 január 1-től eltelt másodperceket számoljuk,

Az x másodperc után jön az x+1, az után meg az x+2.

Egy kernel timer, vagy egy pénzügyi rendszer szempontjából teljesen mindegy, hogy az x+1-et local time-ra átváltva 11:23:46, 23:49:60, vagy 0:0:0 lenne a kiírt szöveg.

Vagy az volt a gond, hogy a linux kernel meg a pénzügyi rendszer átváltotta a másodperceket local time-ra, és aztán ezen ment az időzítés meg az összehasonlítás?

A masodperces felbontas boven keves, plane egy kernel timer eseteben. A 2012-es mokarol reszletek itt es itt.

Nem arra gondoltam, hogy másodperc legyen a granularitás.

Hanem arra, hogy ha a kernel timer, vagy az időpontokat összehasonlító pénzügyi rendszer azt látja, hogy az egyik szám az 12345678.912345 másodperc, a másik meg 12345679.123456 másodperc, akkor megvan minden információ, amire szükségük lehet, és az, hogy az 12345679 másodperc az éppen egy szökőmásodperc és ezért ha az emberek számára szöveggé konvertáljuk, akkor 23 óra 59 perc 60 másodpercként jelenik-e meg, vagy 0 óra 0 perc 0 másodpercként, vagy piros villogó hibaüzenetként, az nem kellene, hogy érdekelje vagy zavarja őket.

A linkelt cikkeket holnap elolvasom, mert kíváncsi vagyok, hogy hogyan sikerült összehozni. Köszi.

"Lehet, hogy naív vagyok, de úgy képzelem ezt, hogy az 1970 január 1-től eltelt másodperceket számoljuk".
Melyik időzóna szerint? 1970. január 1. 00:00 máskor volt Budapesten és máskor New Yorkban.

"Az x másodperc után jön az x+1, az után meg az x+2."
Lásd egy másik hozzászólásomat: ezzel ott a baj, hogy az emberek szeretnek napokban meg hónapokban is gondolkodni, és sajnos ez a fránya Föld olyan, hogy nem képes egész számú másodperc alatt megtenni egy fordulatot a tengelye körül, nem 86400 másodpercből áll egy nap.
Valóban, a másodpercek szépen telnek a világban, ezt méri is a TAI idő, azonban ha mindig TAI idő szerint mérnénk az időt, akkor az éjfél meg a dél folyamatosan elmászna, nem délben delelne a Nap (nem akkor lenne a zeniten).
Jelenleg például a TAI és az UTC között pontosan 37 másodperc eltérés van.

Hasonló ez ahhoz, hogy "egyik nap után jön a másik, majd 365 nap után egy újabb év" is hibás elgondolás lenne, emiatt vannak szökőnapok. Hasonlóan vannak a szökőmásodpercek is. Egyik másodperc után jön a másik, DE nem igaz, hogy 86400 másodperc után jön egy új nap.

Még egy dolog, ami a RedHatos cikkben van: "however, as 23:59:60 does not exist in Unix's implementation of UTC"
Na, látod, ez a gond.

Most vagy én nem értelek téged, vagy te nem értesz engem.

Idézet:
"Lehet, hogy naív vagyok, de úgy képzelem ezt, hogy az 1970 január 1-től eltelt másodperceket számoljuk".
Melyik időzóna szerint? 1970. január 1. 00:00 máskor volt Budapesten és máskor New Yorkban.

Voltaképp teljesen mindegy, amíg egységesen használják.
Konkrétan UTC szerint nézik.

Idézet:
"Az x másodperc után jön az x+1, az után meg az x+2."
Lásd egy másik hozzászólásomat: ezzel ott a baj, hogy az emberek szeretnek napokban meg hónapokban is gondolkodni, és sajnos ez a fránya Föld olyan, hogy nem képes egész számú másodperc alatt megtenni egy fordulatot a tengelye körül, nem 86400 másodpercből áll egy nap.

Hol érdekli a számítógépet, hogy az emberek miben szeretnek gondolkodni?

Ezt írtam feljebb, pont erre:

Idézet:
Egy kernel timer, vagy egy pénzügyi rendszer szempontjából teljesen mindegy, hogy az x+1-et local time-ra átváltva 11:23:46, 23:49:60, vagy 0:0:0 lenne a kiírt szöveg.

Ugyanígy, hol érdekli a gépet, hogy a föld mennyi idő alatt forog éppen ma?

Az emberek által preferált megjelenítéstől és a föld forgásának sebességétől független az eltelt másodpercek száma, mivel a másodperc hossza fix, és egy fix időponttól egyszerűen számoljuk.

Idézet:
Még egy dolog, ami a RedHatos cikkben van: "however, as 23:59:60 does not exist in Unix's implementation of UTC"
Na, látod, ez a gond.

Azt elhiszem, hogy ez gond, hiszen ezek szerint nincs felkészítve a rendszer, hogy helyesen jelenítse meg az emberek számára értelmezhető módon az időpontot ebben az esetben.
De továbbra is úgy gondolom, hogy egy timernek meg egy összehasonlításnak az esetében ez irreleváns, hacsak a programozó nem úgy imlementálta az összehasonlítást, hogy kiíratta emberként értelmezhető formába, aztán azt hasonlítgatta. De ha valami hasonló böszmeség történt, az azért csak nem a szökőmásodperc hibája.

Ez pont nem tartozott bele a "legtöbb eset"-be. Ellentmondás ettől még nincs :-).

Inkább azt kellene emegértened, hogy az idő tárolása és ábrázolása csak segédeszköz. Az "UTC-ként érdemes felfogni" hibás gondolat. Az idő lehet (a teljesség igénye nélkül) történelmi, csillagászati vagy "ügyviteli".
Az első kettőt mellőzve könnyű lesz a helyzeted. Az ügyvitelt általában törvények, kormányrendeletek, szerződések szabályozzák. Ezekben szerepelhetnek pl. "naptári nap", "banki nap" és hasonló kifejezések. Ezeket soha nem UTC-ként, hanem localtime dátum részeként kell értelmezni. Pontosabb meghatározás esetén - az előbbi definícióból kiindulva - az X. nap Y. órájáig a szokásos meghatározás. Azaz elsősorban csak dátummal kell műveletet végezni. Bármilyen konverzió a napnál kisebb egységeket nem érintheti!

A felhasználó gépén a TZ értéke pontosan kisnyúl. Már csak azért tévedés ilyet használni vagy feltételezni, mert felesleges bizonytalansági tényezőt viszel a dátumkezelésbe. A TZ=Europe/Budapest bizonyára sokat segít az Indiában működő, de Amszterdamban szolgáltató call center precicitásán. ;)
Az adatbázisban tárolt adatok sem különböznek az eddigi elvektől. Az adott művelet időpontját szokás eltárolni localtime szerint. Ha még azt is mellérakod, hogy ki volt az a marha, aki elkövette, akkor az indiai operátor azonosítója és az indiai localtime tartozik hozzá. Tiszta káosz! ;)
Másik érdekes példa lehet a CDR feldolgozás, különösen abban az esetben, ha az adatforrás hosszabb ideig elérhetetlen. Elég komoly algoritmus, amikor ki kell számolni az adatgyűjtés/számlázás szempontjából aktuális napot.

Szerintem egy adott feladat és feltételrendszer pontos megértése nélkül nem lehet "csak úgy" egy date paranccsal bármit IS megoldani.

Még ezt tenném hozzá: https://zachholman.com/talk/utc-is-enough-for-everyone-right7

Kedvcsináló:

Idézet:
Programming time, dates, timezones, recurring events, leap seconds... everything is pretty terrible.

The common refrain in the industry is Just use UTC! Just use UTC! And that's correct... sort of. But if you're stuck building software that deals with time, there's so much more to consider.

It's time... to talk about time.

(Also it's time for a lot of time-related puns. Please prepare yourself accordingly.)

En nem latom ebben a falsehoods-ban, hogy

"Every day has a 00:00:00 time"

:P

Ez se igaz? Amikor elvenni kell a szökőmásodpercet, akkor ezt veszik el?

Arról van szó, hogy van olyan, amikor DST-t lépnek át, akkor bizonyos országok bizonyos időben egyszerűen máskor lépik át, mint mi, nem 2-3 között.
Brazília például éjfélkor lép DST-t. Azaz az egyik irányban 23:59:59 után 01:00:00 jön.

Tudom, de erre pont nem warningol a falsehoods

Ah, OK. Köszi

Érdekes egybeesés, hogy én is éppen órát állítok ... egy új szerzeményen. Mondjuk az egy TAG Heuer és egy kicsit egyszerűbb dolgom van vele :D

--
trey @ gépház

"az Oracle: van neki egy DATE tipusa, ami időpontot tárol (másodpercig), ha csak dátumot adunk meg, akkor az idő-rész nulla lesz. A DST-s problémát akár Sql*Plus-ban is elő lehet adni:"
Erre az a megoldás, hogy a dátumkezelést nem bízod az Oracle-re, mert alkalmatlan rá. Amit megtehetsz mondjuk, hogy az adatbázisban ISO 8601 szerint formázott időt tárolsz (stringként), majd a szoftverben ezt beparzolod, és azzal végzel számításokat. Tudom, ez sok CPU-t éget, de ezzel jársz a legbiztosabban.

Az update2-re:
A UNIX date(1) az date and time-ot vesz figyelembe a specifikációja alapján, így kizárólag dátumokkal való számolásra alkalmatlan.
Amúgy a UNIX date(1)-nek nincs is -d paramétere. Valamint a specifikációja előírja, hogy figyelembe veszi a TZ környezeti változó értékét mint időzónát, kivéve, ha -u kapcsolóval használják.
http://pubs.opengroup.org/onlinepubs/9699919799/

"Hány az óra, vekker úr?"
"Hogy mit csinál?"

:DDDD