Nyári időszámítás

C/C++

Nyári időszámítás

  • 2399 megtekintés

( meditor | 2005. 04. 28., cs – 13:30 )

[quote:60181524e5="egmont"][quote:60181524e5="meditor"]Ps: én sosem mondanám más kódjára, hogy gány. Legfeljebb azt, hogy
én nem így csinálnám. De nincs harag (-::

Valszeg más a vérmérsékletünk vagy másmennyire érezzük súlyos szónak a gányolást, ebből akadhat a félreértés. De harag részemről sincs (-::

Ja és mégvalami! Ráadásult az adaframe-ben szereplő stemplinek
összhangban kell lennie a rendszer_log fájlokban lévő idővel!

Szóval szép lassan összeáll, hogy miért van nálam úgy, ahogy van!

( egmont | 2005. 04. 25., h – 23:27 )

[quote:ca57764fac="meditor"]1. 2:59-kor elkezdem mérni a mintadarabot
2. 2 percet mérem
3. 3:00-kor visszaállítom az órát a nyári/téli váltás miatt.
4. 2:01-kor befejezem a minta megmérését.
(az előreállítás pontjait nem írom le.)

Meditor, szerintem te nem vagy tisztában a Unix időkezelésével, és ezért hatalmasat gányolsz. Unix rendszer órája akkor pontos, ha _nem_ tologatod soha sem, ugyanis a kernelnek mindig csak és kizárólag az UTC időt szabad ismernie, amiben nincs tologatás. Ha a helyi időt kérdezed le a megfelelő glibc függvénytől, akkor az a kerneltől kapott UTC időt egy ugrást is tartalmazó időzóna adatbázis szerint konvertálja. Neked nem ez kell, kérdezd tehát le az UTC időt, amit közvetlenül, hót egyenesen megkapsz, megúszol egy helyi időre konvertálást, és sehol semmiféle óratekerés nincs a játékban, minden klafful működik "magától".

( egmont | 2005. 04. 25., h – 23:32 )

[quote:bdc90a7f23="meditor"]Egyébként én a nyári időszámítást egy f@szságnak tartom, mert nem
más mint önbecsapás. Deklarálják azt, hogy X dátumtól kezdve
1 órával hamarabb nyitnak ki a hivatalok, és 1 órával hamarabb
zárnak, az órát meg hagyják békén, jól van az úgy, ahogy van.

Nem hiszem, hogy ez volna a megoldás. Átírni az összes nyitvatartást, menetrendet, átprogramozni az összes időzítő készüléket (pl. sulik csengőórája), arrébbcsúsztatni a mindenki által megszokott tv-műsorok időpontját, és leginkább az agyakban átállítani a megszokott dolgokat, meg az égvilágon minden ilyesmi szerintem milliószor annyi munka volna és végtelenszer annyi kavarodást okozna, mint évente kétszer áttekerni az órát és korrektül megoldani a számítástechnikában felmerülő kérdéseket (melyekre ismert a megoldás, csak tudni kell használni). Azt meg aztán úgysem úszod meg, hogy tekerj, ha utazol. Vagy használjon UTC-t az egész világ? A számítástechnikai kérdésekben igen, ezt kell csinálni, de a valós életben ez nem működik.

( meditor | 2005. 04. 26., k – 07:17 )

[quote:1dccb5e626="egmont"][quote:1dccb5e626="meditor"]1. 2:59-kor elkezdem mérni a mintadarabot
2. 2 percet mérem
3. 3:00-kor visszaállítom az órát a nyári/téli váltás miatt.
4. 2:01-kor befejezem a minta megmérését.
(az előreállítás pontjait nem írom le.)

Meditor, szerintem te nem vagy tisztában a Unix időkezelésével, és ezért hatalmasat gányolsz. Unix rendszer órája akkor pontos, ha _nem_ tologatod soha sem, ugyanis a kernelnek mindig csak és kizárólag az UTC időt szabad ismernie, amiben nincs tologatás. Ha a helyi időt kérdezed le a megfelelő glibc függvénytől, akkor az a kerneltől kapott UTC időt egy ugrást is tartalmazó időzóna adatbázis szerint konvertálja. Neked nem ez kell, kérdezd tehát le az UTC időt, amit közvetlenül, hót egyenesen megkapsz, megúszol egy helyi időre konvertálást, és sehol semmiféle óratekerés nincs a játékban, minden klafful működik "magától".

Nem definiáltuk mit jelent a gányolás, de azt gondolom a "hatalmas
gányolás" egy picit túlzás. Amúgy az elmúlt 10-15 év gányolásainak
eredménye megtekinthető a honlapomon. Nézz körül egy kicsit, aztán
folytathatjuk a vitát. Például szívesen venném, ha megneveznéd
azokat a C függvényeket, amelyek egyenesben visszaadják
az UTC-t.

( wry | 2005. 04. 26., k – 08:09 )

azt hiszem arra gondolt, hogy "rendesen"* beállított gép esetén a gép órája UTC-re van állítva és a glibc függvények a rendszeridőt úgy adják vissza, hogy a annyival tolják el az időt amennyi a te időzónád és az UTC közt van. ha a rendszeridődet nem az UTC-hez állítod be, akkor problémák származhatnak ebből (több useres rendszer esetén), amikor az egyes userek a függvények hívásakor hibás időket kapnak vissza.
egyébként nekem pont ilyen jellegű problémám van most egy serveren, amikor perlből behívom a localtime()-ot és előtte a TZ változót beállítom pl Europe/Budapest-re és totál xar időt ad vissza, ugyanis a rendszeridő nincs UTC-hez állítva.

(ha valamit félreértettem a kettőtök közötti vitából akkor bocs)

* "rendes" beállítás alatt a javasolt és elvárt beállítást értem.

( arrabonus v | 2005. 04. 27., sze – 14:59 )

[quote:03643b3878="wry"]azt hiszem arra gondolt, hogy "rendesen"* beállított gép esetén a gép órája UTC-re van állítva és a glibc függvények a rendszeridőt úgy adják vissza, hogy a annyival tolják el az időt amennyi a te időzónád és az UTC közt van. ha a rendszeridődet nem az UTC-hez állítod be, akkor problémák származhatnak ebből (több useres rendszer esetén), amikor az egyes userek a függvények hívásakor hibás időket kapnak vissza.
egyébként nekem pont ilyen jellegű problémám van most egy serveren, amikor perlből behívom a localtime()-ot és előtte a TZ változót beállítom pl Europe/Budapest-re és totál xar időt ad vissza, ugyanis a rendszeridő nincs UTC-hez állítva.

(ha valamit félreértettem a kettőtök közötti vitából akkor bocs)

* "rendes" beállítás alatt a javasolt és elvárt beállítást értem.

Abban az esetben, ha a gépen windows is használatban van nem állíthatod UTC-re a gép óráját, mert a win hibásan kezeli az időt. (Windows guruk majd kijavítanak. :D )
Debian rendszernél a telepítő megkérdezi, hogy UTC vagy localtime szerint jár-e a gép órája és ettől kezdve korrektül kezeli mindkét esetet.

De visszatérve az erdeti problémára: sikerült egy majdnem tökéletes megoldást találnom.

A problémát az okozta, hogy adatbázisba mentéskor GMT-re konvertáltam az időt, majd beolvasáskor úgy próbáltam visszaalakítani, hogy közben a
[code:1:03643b3878] tsr.tm_isdst=0; [/code:1:03643b3878] beállítást használtam minden esetben.

Pedig a manual szerint: [code:1:03643b3878] tm_isdst
A flag that indicates whether daylight saving time is in effect
at the time described. The value is positive if daylight saving
time is in effect, zero if it is not, and negative if the infor-
mation is not available.
[/code:1:03643b3878]

Vagyis nem kell tudnom, hogy milyen időszámítás volt érvényben, egyszerűen negatív értéket megadva tm_isdst-nek a megfelelő függvények tökéletesen működnek.

Sajnos az őszi váltáskor egyértelműen meg kell mondani, hogy a hajnali 2-3 közötti időpontok nyári, vagy normál időszámítás szerint értendőek-e.

Köszi a segítséget mindenkinek!

Arrabonus

( egmont | 2005. 04. 27., sze – 16:27 )

[quote:05d7c2deb7="arrabonus"][quote:05d7c2deb7="wry"]azt hiszem arra gondolt, hogy "rendesen"* beállított gép esetén a gép órája UTC-re van állítva és a glibc függvények a rendszeridőt úgy adják vissza, hogy a annyival tolják el az időt amennyi a te időzónád és az UTC közt van. ha a rendszeridődet nem az UTC-hez állítod be, akkor problémák származhatnak ebből (több useres rendszer esetén), amikor az egyes userek a függvények hívásakor hibás időket kapnak vissza.

Abban az esetben, ha a gépen windows is használatban van nem állíthatod UTC-re a gép óráját, mert a win hibásan kezeli az időt. (Windows guruk majd kijavítanak. :D )
Debian rendszernél a telepítő megkérdezi, hogy UTC vagy localtime szerint jár-e a gép órája és ettől kezdve korrektül kezeli mindkét esetet.

Szerintem másról beszéltek, wry a Linux kernel által kezelt óráról, arrabonus pedig a CMOS óráról. Amiről beszéltek, abban mindkettőtöknek tök igaza van :-)

Arrabonus, jó hogy megírtad az eredményt, az isdst=-1 újdonság számomra is, eddig elkerülte a figyelmemet, úgy fest hogy tényleg ez a legegyszerűbb út. köszi :)

( arrabonus v | 2005. 04. 25., h – 13:43 )

Sziasztok!

Egy Postgres táblából kiolvasott "timestamp" mező tartalmát kellene "timeval" típussá konvertálnom. Az eddigi, nem túl szép megoldás:

[code:1:ec88d773f0]
timeval timestamptotimeval(char *timestamp) {
timeval t;
time_t tt;
char *c;
int usec;
tm tsr;

tsr.tm_isdst=0;

c=timestamp;
sscanf(c,"%d",&tsr.tm_year); tsr.tm_year=tsr.tm_year-1900;
c=c+5;
sscanf(c,"%d",&tsr.tm_mon); tsr.tm_mon--;
c=c+3;
sscanf(c,"%d",&tsr.tm_mday);
c=c+3;
sscanf(c,"%d",&tsr.tm_hour);
c=c+3;
sscanf(c,"%d",&tsr.tm_min);
c=c+3;
sscanf(c,"%d",&tsr.tm_sec);
c=c+3;
sscanf(c,"%d",&usec);

tt=mktime(&tsr);
tt=tt+tsr.tm_gmtoff;

t.tv_sec=tt;
t.tv_usec=usec;

return t;
};
[/code:1:ec88d773f0]

Ez remekül működött, amíg téli időszámítás szerinti értékeket kellett konvertálni.

Nyári időszámítás esetén az

[code:1:ec88d773f0] tsr.tm_isdst=0;
[/code:1:ec88d773f0]

értékadásban nulla helyett pozitív egészet kellene használnom.

Egy olyan időtálló algoritmusra lenne szükségem, amelyik az időzóna nélküli helyi időről el tudja dönteni, hogy akkor nyári időszámítás volt-e érvényben.

Tud-e valaki segíteni?

Köszi!

Arrabonus

( egmont | 2005. 04. 25., h – 13:52 )

Szerintem az mktime() figyelmen kívül hagyja az is_dst értéket, bár ebben nem vagyok biztos. Közelítő megoldás a problémádra: az mktime eredményét alakítsd vissza egy localtime() hívással és ott nézd meg a kapott is_dst értéket.

Tökéletes megoldás nem létezik a problémára elvi síkon sem, hiszen van olyan helyi idő, ami lehet téli meg nyári időszámítás is (október utolsó vasárnapja hajnali 2 óra akárhány perc).

( egmont | 2005. 04. 26., k – 14:07 )

gettimeofday(), time(), ftime(), clock_gettime() mind visszaadják az UTC időt egy speciális formátumban: az 1970. jan. 1. 0 óra 0 perc UTC óta eltelt nemszökőmásodpercek számát.
A gmtime() és gmtime_r() szolgál ennek a szétrobbantására év-hó-nap stb. mezőkre.
Ezen függvények egyike sem törődik semmiféle időzónásdival vagy helyi idővel, nincs bennük semmiféle ugrás vagy tologatás. Így kizárólag ezekre építve tökéletes időkezelést lehet megvalósítani bármely alkalmazásban. A hely időre alakításra (localtime() és localtime_r()) csak a felhasználó előtti megjelenítés kapcsán kell hogy szükség legyen, a helyi idő megemésztésére pedig normálisan megtervezett rendszer esetén soha nem szabad hogy szükség legyen, de ha mégis van, akkor még vannak lehetséges kerülő megoldások.

meditor: Egyéb hozzászólasaid alapján tudom hogy nem ma kezdted és volt már nagyon sok számomra szimpatikus megjegyzésed a hup fórumon, talán te is tudhatod hogy én sem ma kezdtem és nem is kicsiben nyomom a linuxozást, nem általában véve a szakmai tudásodat kritizálom, de úgy tűnik számomra ezen topic hozzászólásai alapján, hogy a pontos idő kezelését nem ismered és ezért mindent a feje tetejére állító kerülő megoldást keresel ahelyett hogy a hivatalos, szép, jól megtervezett, jól járható úton járnál.

Még mielőtt a vitát folytatnánk, ajánlom figyelmedbe az UHU tudásbázisából a pontos idővel kapcsolatban írt cikkemet, mely ideiglenesen itt lelhető fel: http://ojjektum.uhulinux.hu/~egmont/uhu-tudasbazis.html#68 és nagy része UHU-független.

( arrabonus v | 2005. 04. 25., h – 14:07 )

[quote:94f9a03e21="egmont"]Szerintem az mktime() figyelmen kívül hagyja az is_dst értéket, bár ebben nem vagyok biztos. Közelítő megoldás a problémádra: az mktime eredményét alakítsd vissza egy localtime() hívással és ott nézd meg a kapott is_dst értéket.

Tökéletes megoldás nem létezik a problémára elvi síkon sem, hiszen van olyan helyi idő, ami lehet téli meg nyári időszámítás is (október utolsó vasárnapja hajnali 2 óra akárhány perc).

Sajnos nem hagyja figyelmen kívül :cry: Minden betöltés-visszamentés ciklus egy órával növeli az értéket :lol:

A localtime megoldást kipróbálom.

Köszi

( meditor | 2005. 04. 27., sze – 18:15 )

egmontnak:

Saját rendszereimben az ftime()-ot használom, ezt ugyan nemigen
ajánlgatják a man-ok, de számomra ez a legegyszerűbb. A mérési
adatframe-ekben ugyanis saját időfomátumot használok adatátviteli
okokból (ha sok 10ezer Hz-cel dőlnek az adatok nem mindegy, hogy
mekkora egy adatframe). Ezeket az időkezelő rutinokat 1999-2000-ben
írtam és alaposan körbejártam a kérdéskört. Nem véletlenül alakult
ki az a megoldás, ami kialakult. Az is igaz viszont, hogy miután
megoldódott a dolog, nemnagyon foglalkoztam a kérdéssel. Könnyen
lehet, hogy azóta máshol kel a nap.

Járt utat járatlanért: erről az a véleményem, hogy időnként le kell
térni. (Jó példa erre: a mintavételező ütemezőjét az RTC megszakításról
veszem olyan beállításokkal, amelyek korábban kifejezetten
ellenjavaltak voltak.)

Na, üdv.

Ps: én sosem mondanám más kódjára, hogy gány. Legfeljebb azt, hogy
én nem így csinálnám. De nincs harag (-::

( meditor | 2005. 04. 25., h – 14:11 )

[quote:0ee3550ffd="egmont"]Szerintem az mktime() figyelmen kívül hagyja az is_dst értéket, bár ebben nem vagyok biztos. Közelítő megoldás a problémádra: az mktime eredményét alakítsd vissza egy localtime() hívással és ott nézd meg a kapott is_dst értéket.

Tökéletes megoldás nem létezik a problémára elvi síkon sem, hiszen van olyan helyi idő, ami lehet téli meg nyári időszámítás is (október utolsó vasárnapja hajnali 2 óra akárhány perc).

Az én problémám a nyári időszámítással. Témakör: méréstechnika.
Jönnek a mérési adatok, folyamatosan asszinkron módon. Megy az
éjszakai műszak, egyszercsak műszak közepén kitör a nyár (vagy a tél).
Az egyik esetben egy minta mérése akár egy óránál tovább is tarthat
(normális esetben 2-3 perc), a másik esetben befejeződik a minta
mérése, mielőtt a mérést megkezdték volna.

Én azt a megoldást választottam hogy:

1/ UTC van a gépeken (tzone)
2/ Localtime a cmosban (kernel)

És közöltem a megrendelőkkel hogy az időt csillagászatilag és
nem adminisztratíve kell érteni.

Az én esetemben elvi megoldás sem létezik a nyári/téli váltásra,
mert az még csak hagyján hogy néha ugrik egy-egy órát az időtengely,
de időnként vannak olyan szakaszai is, hogy látszólag visszafelé
folyik.

( arrabonus v | 2005. 04. 27., sze – 18:19 )

[quote:5aacaea2fb="egmont"]Szerintem másról beszéltek, wry a Linux kernel által kezelt óráról, arrabonus pedig a CMOS óráról. Amiről beszéltek, abban mindkettőtöknek tök igaza van :-)

A unixok belső órája (számlálója) definíció szerint az 1970 január 1.-je óta eltelt másodperceket számolja. Ezt tudtam korábbann is.
[quote:5aacaea2fb="egmont"]Arrabonus, jó hogy megírtad az eredményt, az isdst=-1 újdonság számomra is, eddig elkerülte a figyelmemet, úgy fest hogy tényleg ez a legegyszerűbb út. köszi :)

Sajnos számomra is! :D
Egyszer talán megtanulok manualt olvasni. :oops:

Arrabonus

( arrabonus v | 2005. 04. 25., h – 14:19 )

A feladat hasonló. Ezek az adatok egy áramszolgáltató vállalat diszpécserközpontjának mérésadatgyűjő-megjelenítő rendszeréből származnak. Sajnos nekünk kell igazodnunk, nem tudjuk megváltoztatni a tárolt időpont formátumát.

Arrabonus

( egmont | 2005. 04. 25., h – 14:19 )

Én azt a megoldást választottam hogy:

1/ UTC van a gépeken (tzone)
2/ Localtime a cmosban (kernel)

Nem értelek. Kitalálsz valamit, ami rosszabb, mint ami alapból a kernelben van. Meg azt sem értem hogy a cmos-nak mi köze a kernelhez. A Unixok kernele mindig csak az UTC-t tudja. Az időzóna segítségével lehet ezt akár helyi időként is megjeleníteni. Ez jó így. Óratologatáskor semmi teendő nincs. A kritikus alkalmazásokat pedig úgy kell megírni, hogy mindig UTC időcímkét (vagy unix időt) ábrázoljanak.

( arrabonus v | 2005. 04. 25., h – 14:24 )

[quote:3d20b580cc="egmont"] A kritikus alkalmazásokat pedig úgy kell megírni, hogy mindig UTC időcímkét (vagy unix időt) ábrázoljanak.

Néha más rendszerekhez kell igazodni. Localtime-ot kapunk és ezen nem tudunk változtatni. :(

A visszafelé konverzió pedig nem egyértelmű...

Arrabonus

( egmont | 2005. 04. 25., h – 14:24 )

Érdemes lehet még lenyomozni, hogy a "date" parancs mit csinál a dátum megemésztésekor. Próbáld ki:
$ date +%s -d '2005/03/27 01:59:59'
$ date +%s -d '2005/03/27 03:00:00'
ez szerintem azt csinálja ami neked kell.

( egmont | 2005. 04. 25., h – 14:25 )

[quote:a2cc1b97f2="arrabonus"]Néha más rendszerekhez kell igazodni. Localtime-ot kapunk és ezen nem tudunk változtatni. :(

Tökéletesen értelek, és a megközelítés is jó: az input adatot azonnal át kell alakítani valami normális formátumra és utána rendesen azzal dolgozni.
meditor-t nem értem, mert ő úgy túnik számomra hogy az egész Linux órakezelését cakkumpakk megpróbálja megerőszakolni és átalakítani másmilyenre, az inputhoz igazítva, ahelyett hogy az inputot alakítaná át.

( arrabonus v | 2005. 04. 25., h – 14:31 )

[quote:f7adaf1201="egmont"][quote:f7adaf1201="arrabonus"]Néha más rendszerekhez kell igazodni. Localtime-ot kapunk és ezen nem tudunk változtatni. :(

Tökéletesen értelek, és a megközelítés is jó: az input adatot azonnal át kell alakítani valami normális formátumra és utána rendesen azzal dolgozni.
meditor-t nem értem, mert ő úgy túnik számomra hogy az egész Linux órakezelését cakkumpakk megpróbálja megerőszakolni és átalakítani másmilyenre, az inputhoz igazítva, ahelyett hogy az inputot alakítaná át.

Az input adatokat nem on-line kapjuk, emiatt egy későbbi időpontban kell konvertálnunk. Ezzel a problémát visszavezettük az eredetire :P

( meditor | 2005. 04. 25., h – 14:36 )

[quote:4758b79e77="egmont"]

Én azt a megoldást választottam hogy:

1/ UTC van a gépeken (tzone)
2/ Localtime a cmosban (kernel)

Nem értelek. Kitalálsz valamit, ami rosszabb, mint ami alapból a kernelben van. Meg azt sem értem hogy a cmos-nak mi köze a kernelhez. A Unixok kernele mindig csak az UTC-t tudja. Az időzóna segítségével lehet ezt akár helyi időként is megjeleníteni. Ez jó így. Óratologatáskor semmi teendő nincs. A kritikus alkalmazásokat pedig úgy kell megírni, hogy mindig UTC időcímkét (vagy unix időt) ábrázoljanak.

Csakhogy a C függvények használatakor a dst flag bekavar, ahogy
te is megállapítottad. a cmos és a kernel úgy függ össze, hogy
van egy opció a kernelben, ami a GMT-re vonatkozik.

"Óratologatáskor semmi tennivaló nincs" akkor mégegyszer:

1. 2:59-kor elkezdem mérni a mintadarabot
2. 2 percet mérem
3. 3:00-kor visszaállítom az órát a nyári/téli váltás miatt.
4. 2:01-kor befejezem a minta megmérését.
(az előreállítás pontjait nem írom le.)

Szerintem ez nem frankó. Lehetne úgy is szervezni, hogy egy órát
nem dolgoznak a fiúk, mint a vasútnál, ahol megállnak 1 órára
a vonatok a nyílt pályán (ekkora marhaságot!!!), de ahol
teljesítménybérbe dolgoznak, ott ez az utasítás nem lenne
népszerű.

Hidd el, az én esetemben az a legegyszerűbb, hogy becsapod a gépet és
azt mondod neki, hogy itt GMT van, meg UTC meg ilyesmi.

( egmont | 2005. 04. 27., sze – 20:36 )

[quote:91c6b33083="arrabonus"]A unixok belső órája (számlálója) definíció szerint az 1970 január 1.-je óta eltelt másodperceket számolja.

Hadd pontosítsak:
A unixok belső órája (számlálója) definíció szerint az 1970. január 1-je 0 óra 0 perc 0 másodperc _UTC_ óta eltelt másodperceket számolja. Ez tehát nem az az időpont, amikor Magyarországon beköszöntött az 1970-es év, hanem annál 1 órával későbbi időpont, amikor Greenwich-ben beköszöntött az 1970. Ja és mellesleg a Unix idő a szökőmásodperceket is figyelmen kívül hagyja, amikből azóta tudtommal 22 darab volt.

( gsimon | 2005. 04. 25., h – 14:53 )

Az a baja a kollégának, hogy ő már készen kapja az időbélyeges adatokat vmi ilyenformán:
00:00:00 ....
00:01:12 ...
...
01:57:11 ...
03:07:11 ... (itt 10 perc telt el!)
...
(fél év)
00:00:00 ...
01:00:00 ...
(*)
02:20:00 ...
02:45:00 ...
02:59:00 ...
02:09:00 ... (itt is 10 perc telt el!)
(*)
02:20:00 ...
02:45:00 ...
02:59:00 ...
03:11:22 ...

A logikai gubanc meg információvesztés ott van, hogy még ha figyeli is az időpontokat, hogy átmennek-e a téli/nyári váltásvonalon, akkor sem tudja eldönteni, hogy ha a két (*) közötti rész nincs ott, akkor a folytatás most "melyik két óra x perc", a visszahúzás előtti v. mögötti.

Ha egyéb információd nincs (pl. az adatok időrendben jönnek és két adat között garantáltan nem telhet el óra), akkor a feladatnak nem létezik egyértelmű megoldása.

Az viszont előfordulhat, hogy az az évi +- egy óra a kutyát sem érdekli, ergo kérdezd meg a főnököd, hogy mit csinálj az ilyen esetekkel, döntse el ő, lehet, hogy azt mondja, h. fütyülj az egészre, amit itt elvesztesz azt megnyered a párján :)

( egmont | 2005. 04. 27., sze – 20:40 )

meditornak:

Az egyes kernel értékeknek (például a belső óra értéke) és a glibc függvényeknek (ftime() és társai) nem csak szintaktikájuk van rögzítve a szabványban (milyen típusú adat stb.), hanem szemantikájuk is (vagyis mi az emberi értelmezése az általuk kezelt adatoknak). Ha valaki direkt más szemantikával ad értéket egy ilyen változónak, például direkt nem a helyes időt tárolja el idő gyanánt hanem valami mást, az gányolás. Ezt nem csak más kódjára mondom, ha én csinálnék ilyet, az én kódomra is azt mondanám hogy gányolás. Igen, van amikor gányul kódolok mert úgy jönnek ki egyszerűbben a dolgok, de olyankor ezt felvállalom :-) és természetesen igyekszem kerülni az ilyet.

( egmont | 2005. 04. 27., sze – 20:48 )

[quote:5dad31c201="meditor"]Ps: én sosem mondanám más kódjára, hogy gány. Legfeljebb azt, hogy
én nem így csinálnám. De nincs harag (-::

Valszeg más a vérmérsékletünk vagy másmennyire érezzük súlyos szónak a gányolást, ebből akadhat a félreértés. De harag részemről sincs (-::

( meditor | 2005. 04. 25., h – 15:04 )

[quote:a54ddf15e1="gsimon"]Az a baja a kollégának, hogy ő már készen kapja az időbélyeges adatokat vmi ilyenformán:
00:00:00 ....
00:01:12 ...
...
01:57:11 ...
03:07:11 ... (itt 10 perc telt el!)
...
(fél év)
00:00:00 ...
01:00:00 ...
(*)
02:20:00 ...
02:45:00 ...
02:59:00 ...
02:09:00 ... (itt is 10 perc telt el!)
(*)
02:20:00 ...
02:45:00 ...
02:59:00 ...
03:11:22 ...

A logikai gubanc meg információvesztés ott van, hogy még ha figyeli is az időpontokat, hogy átmennek-e a téli/nyári váltásvonalon, akkor sem tudja eldönteni, hogy ha a két (*) közötti rész nincs ott, akkor a folytatás most "melyik két óra x perc", a visszahúzás előtti v. mögötti.

Ha egyéb információd nincs (pl. az adatok időrendben jönnek és két adat között garantáltan nem telhet el óra), akkor a feladatnak nem létezik egyértelmű megoldása.

Az viszont előfordulhat, hogy az az évi +- egy óra a kutyát sem érdekli, ergo kérdezd meg a főnököd, hogy mit csinálj az ilyen esetekkel, döntse el ő, lehet, hogy azt mondja, h. fütyülj az egészre, amit itt elvesztesz azt megnyered a párján :)

Így van, pontosan ezt igyekeztem én is megmagyarázni és mivel én nem
kapok kívülről adatokat (én stemplizem őket), illetve ilyen típusú
információvesztés nem engedhető meg, megtehettem azt, hogy a csillagidőhöz igazítok mindent.

A lényeg valóban ez: az igazi időkülönbség akkor sem állapítható
meg egyértelműen, ha tudod, hogy időátállítás történt.

Egyébként én a nyári időszámítást egy f@szságnak tartom, mert nem
más mint önbecsapás. Deklarálják azt, hogy X dátumtól kezdve
1 órával hamarabb nyitnak ki a hivatalok, és 1 órával hamarabb
zárnak, az órát meg hagyják békén, jól van az úgy, ahogy van.

( LeslieT | 2005. 04. 25., h – 18:02 )

[quote:cf3b4dce50="arrabonus"]Sziasztok!

Egy Postgres táblából kiolvasott "timestamp" mező tartalmát kellene "timeval" típussá konvertálnom.

Hello,

Először is a timestamp helyett használj timestamptz tipusú mezőt. Aztán olvasd ki közvetlenül unix timestamp-ként, és azt rakd a timeval struktúrádba.

pl:
# select extract(epoch from current_timestamp(0)) as sec;
sec
------------
1114444420
(1 row)

# select extract('microseconds' from now()) as usec;
usec
----------
23327045
(1 row)