óra

 ( fantom | 2005. október 11., kedd - 17:24 )

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ő.

Hi!

Én nem szeretném kritizálni az oldalt, de úgy érzem valami nincs rendben.

Konkrétan a világidő Blokk nem pontos.
Egy ilyen szinvonalas oldalon sztem ez megengedhetetlen. :mrgreen:
Ugyanis ha megnézem a GMT-et az kerek két órával kevesebbet mutat mint a miénk.
Tudtommal mi még csak GMT+1 es zónában vagyunk.

Ez biztos valami apró tévedés fele ezért gondolom csak figyelmetlenség.

Remélem az oldal még sokáig fogja a hireket szolgáltatni és egyben a Magyarországi linux-osok egyik kedvenc oldala marad

A GMT most tényleg 2 órával kevesebb! Valószínűleg a nyári időszámítás miatt.
http://wwp.greenwichmeantime.com/

Itt a HUPon nekem a "London GMT" ugyanazt mutatja, mint a "helyi idő", szóval nem tudom, mi van (mellesleg mindkettő a pontos közép-európai időt mutatja).

[quote:25891de727="fantom"]Tudtommal mi még csak GMT+1 es zónában vagyunk.[/quote:25891de727]
Rosszul tudod.

[quote:cad8527cb6="fantom"]Hi!

Én nem szeretném kritizálni az oldalt, de úgy érzem valami nincs rendben.

Konkrétan a világidő Blokk nem pontos.
Egy ilyen szinvonalas oldalon sztem ez megengedhetetlen. :mrgreen:
Ugyanis ha megnézem a GMT-et az kerek két órával kevesebbet mutat mint a miénk.
Tudtommal mi még csak GMT+1 es zónában vagyunk.
[/quote:cad8527cb6]Nem eppen. Nem akarlak elkeseriteni, de mi most (oktober utolso vasarnapjaig) a [b:cad8527cb6]CEST[/b:cad8527cb6]-ben vagyunk, telen pedig a [b:cad8527cb6]CET[/b:cad8527cb6]-ben. Amugy a [b:cad8527cb6]GMT+1[/b:cad8527cb6] a Greenwich Mean Time elott jar 1 oraval, azaz amikor a [b:cad8527cb6]GMT[/b:cad8527cb6] 7:00 akkor a [b:cad8527cb6]GMT+1[/b:cad8527cb6] idozonaban 6:00 van :-). A nap szerinti kozepido Mo.-n a [b:cad8527cb6]GMT-1[/b:cad8527cb6] idozonahoz van legkozelebb (ha jol emlekszem 10-15 perc diffi van valamelyik iranyban) amugy...[quote:cad8527cb6="fantom"]

Ez biztos valami apró tévedés fele ezért gondolom csak figyelmetlenség.

Remélem az oldal még sokáig fogja a hireket szolgáltatni és egyben a Magyarországi linux-osok egyik kedvenc oldala marad[/quote:cad8527cb6]
Zsiraf

p.s.: mielott pofazol please: [b:cad8527cb6]RTFM[/b:cad8527cb6] pl.:[url=http://www.timeanddate.com/library/abbreviations/timezones]Time and Date dot COM[/url]

Ez a PHPNuke hibája, nem Trey-é. Ha megnézitek a hozzászólások idejét, az nem egyezik a helyi idővel.

[quote:6cec0104a7="egmont"][quote:6cec0104a7="fantom"]Tudtommal mi még csak GMT+1 es zónában vagyunk.[/quote:6cec0104a7]
Rosszul tudod.[/quote:6cec0104a7]

sztem felreertitek a dudet, tuti az atlanti oceanrol tolja :)

[quote:6cec0104a7="norcrys"]Ez a PHPNuke hibája, nem Trey-é. Ha megnézitek a hozzászólások idejét, az nem egyezik a helyi idővel.[/quote:6cec0104a7]

nalad, de ez nem a spagettikodnuke hibaja

a gond - független attól kihez/mihez tartozik az időzóna listát generáló kód - azzal vagyon, hogy GMT+x alapján nem értelmes időzónát kiválasztani, mivel más-más időzónák más időmennyiséget adnak (vegy vesznek el, mert az északi/déli féltekétől is függ) a GMT (jobb körökben UTC) -hez.
Dél-Ausztrália államban pl 30 percet adnak hozzá, Brisbaneben meg, ami egy vonalban van Sydneyvel és Hobarttal is, semennyit, mivel nincsen téli-nyári időszámítás. hovatovább Hobartban két héttel előbb állítják át az órákat mint Sydneyben, pedig nem sok értelme van ennek sem... az igazi megoldás vagy az lenne, ha egy listából választani lehetne, vagy ha mindenki beüthetné a zoneinfo dirben lévő Olson formatban lévő fileokat (amely mellesleg a világ egyik leggyökerebb formátuma, de lehet, hogy ezen véleményemben egyedül vagyok).
apropó, ha valaki merő unalmában összepattintana Perlben, Rubyban vagy Pythonban egy Olson tzfile parsert, az azonnal értesítsen! (Perlhez pl ugyanis nincs ilyen a default modulok között, ezért az ember vagy a "date" parancsot hívja meg, vagy a $TZ-t kufircolja, de ez mod_perl alatt nem engedélyezett).

apropo..
http://www.twinsun.com/tz/tz-link.htm

[quote:ae20579875="snq-"]
[quote:ae20579875="norcrys"]Ez a PHPNuke hibája, nem Trey-é. Ha megnézitek a hozzászólások idejét, az nem egyezik a helyi idővel.[/quote:ae20579875]

nalad, de ez nem a spagettikodnuke hibaja[/quote:ae20579875]

Látom, csipkelődős kedvedben vagy. A phpnuke - phpBB párosnak van ez a hibája, eltérő időzónát valósítanak meg, mást kell beállítani az egyikben és a másikban.

Vagy esetleg két dátumot vezetni:
- Egyet a küldő ad, olyan számítással és formátummal, amivel akarja. Ennek pusztán annyi a célja, hogy tudhassam, hogy ő vajh délelőtt vagy éjszaka írta. Innentől aztán tőlem a hónapokat nevezheti a francia forradalmi naptár szerint, az éveket számolhatja a Han dinasztia kezdetétől, oszthatja a napot 32 órára, vezethet be naponta 2 és félszer szökő-másfél-percet, mindegy.
- Egyet pedig a szerver jegyez, systime-ban. Ennek a célja a beérkezési idő, aminek a szerepe a hozzászólások sorbarendezése ill. a keresések időkorlátozása.

Kicsit nonszensznek tartom, hogy még egy levél küldésénél is:
- a küldő gépe _tudja_ az időt systime-ban
- ebből a helyi szokásoknak megfelelően csinál egy szöveges időbélyeget
- amit megkap az én gépem, és csinál belőle systime-ot
(Ehhez persze tudni kell, hogy a világ mely részén mennyi az eltolódás, mikor kezdik a nyári időszámítást, stb.)
- majd beformázza nekem, hogy én is a helyi szokásaim szerint lássam

Nem egyszerűbb lenne, ha a gépek az egymás közötti kommunikációban nem egy embernek kitalált formátumot erőltetnének, hanem egy tök egyértelműt pl. systime, az oda-vissza konverziót meg a feladáskor és a megjelenítéskor végeznék?
Csak megjegyzem, hogy a 'network byte order' koncepciója pont ugyanerre alapul: az én gépem kezelheti az egészeket 19 biten ábrázolt -2-es számrendszerben, egy tcp portszámot akkor is _úgy kell_ a drótra tennem, ahogy, aztán a többi már a htons/ntohs dolga mindkét oldalon. Működik is zökkenőmentesen...
Ellentétben pl. az UTF8-as kódolással, ahl ugye az elején kell egy Byte Order Mark-ot küldeni, hogy a túloldal tudhassa, hogy vajon én hogy ábrázolom a számokat. Mi köze hozzá, miért kell mindenkinek minden ábrázolást kezelni tudnia? Mert képtelenek voltak egy ökölszabállyal eldönteni, hogy "ez márpedig big-endian lesz"? Mennyi vesződséget okoz ez a határozatlanság?

Nem azér', de nem mindegy, mit mutat az a vacak óra? :D

[quote:82d1d9400b="Frantique"]Nem azér', de nem mindegy, mit mutat az a vacak óra? :D[/quote:82d1d9400b]
Ha pl. tárgyalásra mégy, akkor általában nem értékelik az olyasmit, hogy "bocsi, azt hittem, két órával később lesz". Hogy a repülőgép-menetrendekről már ne is beszéljünk...

"Szept 11, reggel:
- Elnök úr, Szaddam Husszein vagyok, engedje meg, hogy részvétemet fejezzem ki az országát ért szörnyű csapás miatt!
- Itt Bush, de miért ébresztett fel, és egyáltalán, miről beszél maga, ember?!
- Rohadt időzónák, a francba!"

[quote:5a5979d1e4="gsimon"]pl. az UTF8-as kódolással, ahl ugye az elején kell egy Byte Order Mark-ot küldeni[/quote:5a5979d1e4]

utf-16 jobb pelda lett volna, mert imo utf-8-nal nem tul sok ertelme van a bomnak

GMT-nel nincs nyari idoszamitas (az a mindenkori _valos_ ido). Azaz alaphelyzetben GMT+1 vagyunk, nyaron viszont GMT+2 (mert akkor ugye onkenyesen eltolunk 1 orat).

[quote:2b984cf0f4="geronimo"]GMT-nel nincs nyari idoszamitas (az a mindenkori _valos_ ido). Azaz alaphelyzetben GMT+1 vagyunk, nyaron viszont GMT+2 (mert akkor ugye onkenyesen eltolunk 1 orat).[/quote:2b984cf0f4]
Hát ez az, önkényesen. Csak aztán azt nem értem, hogy pl. miért kell az a cécó, hogy a túlvég tudja, hogy mennyi az abszolut idő, ehhez számolgatja, hogy mikor tologat merre, precízen beformázza (az angol hónapnév/napnév-rövidítésekkel), leírja, az én oldalamon ezt kielemzem, visszaszámolom abszolutba, átszámolom a saját tologatásomnak megfelelően, aztán a megjelenítéshez átformázom a saját szokásaim szerint (magyar hónapnév/napnév-rövidítésekre), csak hogy megtudjam, hogy a (nekem) reggeli telefonbeszélgetésünk után mennyi idővel küldte az ausztrál kolléga a levelet/hozzászólást.
Abszolut időbélyeg esetén az odatologat-formáz-elemez-visszatologat lépések kihagyhatóak lennének, sok félreértést takarítva meg ezzel.
Meg aztán megint, miért kéne a világ minden gépének tudnia a "Csen-dinasztia 4536. évének húsvét hétfője Bivalyröcsöge reggel 8 órát" nyugat-minnesotai discordiánus naptárra konvertálni :) ?

IIRC "erre találták ki" az UTC-t. Aminek se GMT-hez, se valós időhöz, se semmihez semmi köze, mégis ezt használják normális UNIX (levelező) rendszerek. IIRC.

(Btw nézd meg a rendszered óráját Linuxban. Akárhol is vagy, akárhogy is állítottad be, az bizony UTC-ben jár, és mindenféle program a TZ alapján jelenít meg időt, akkor számolva a kernel órájából. Még a syslogba is az átszámított idő kerül, pedig a kernel óra nem állítódik semerre még téli/nyári váltáskor sem. Na és persze ennek semmi köze a rendszered hardverórájához, ugyebár. Ja és: "/msg mojojojo , maniacs" ;) )

[quote:83132e7625="szaszg"]Amugy a [b:83132e7625]GMT+1[/b:83132e7625] a Greenwich Mean Time elott jar 1 oraval, azaz amikor a [b:83132e7625]GMT[/b:83132e7625] 7:00 akkor a [b:83132e7625]GMT+1[/b:83132e7625] idozonaban 6:00 van :-).[/quote:83132e7625]
Hat en a GMT zonaba vagyok (UK) es itt egy oraval kevesebb van mint Mo-on. (Momentan 12:22)

A forummotor pedig pont az ellenkezoiranyba jelzi nalam az elozo postomat: Szerd Okt 12, 2005 11:22 am

[quote:5afe368565="gsimon"]Kicsit nonszensznek tartom, hogy még egy levél küldésénél is:
- a küldő gépe _tudja_ az időt systime-ban
[...]
[/quote:5afe368565]
gsimon: totál igazat adok neked mindenben, kivéve az UTF8 BOM-ot, amint snq- is írta, valszeg UTF16-ra gondoltál, az UTF8 hálistennek egyértelmű.

boobaa: ja, a syslog gáz, hogy lokális időt ír, és az is gáz, hogy nem ír évszámot...

gsimon, egyébként tudod hogy mi a leggázabb ilyen téren? Legalábbis szerintem... Az Id3v2 tag-ekben az ékezetkódolás. 2 biten meg kell mondanod, hogy Latin-1, UTF-16-BE (asszem, de lehet hogy épp LE), UTF-16 with BOM vagy UTF-8 kódolást fogsz használni, és aztán azt a kódolást kell használnod. Meg lehet nézni hogy hány id3 dekódoló létezik, amelyik jól kezeli ezt, és hány, amelyik nem. Nem lett volna sokkal egyszerűbb _egy_ konkrét Unicode-kompatibilis kódolásra rábökni a szabványban hogy márpedig azt kell használni és kész? Akkor szerintem most lényegesen több mp3-lejátszó jelenítené meg ékezethelyesen a címeket (na meg persze lényegesen több tag-készítő program tárolná el helyesen).

[quote:f5756676bd="egmont"]gsimon, egyébként tudod hogy mi a leggázabb ilyen téren? Legalábbis szerintem...[/quote:f5756676bd]
"Az a jó a szabványokban, hogy olyan sok van belőlük, és ha valamelyik nem tetszik, simán megvárhatod a jövő évi újabb változatokat" :). Nyugi, voltak már nagyobb baklövések is a szabad világban. Pl. majd' eldobtam az agyam a jó öreg telnet protokoll kapcsán, amikor olvastam, hogy van egy ENVIRON nevű al-opciója (36) meg egy NEW-ENVIRON (39), amik a környezeti változókat piszkálják, és annyi közöttük a különbség, hogy a változó nevét és értékét pont felcserélve kezelik (rfc 1408 és 1572).
A történeti háttere a dolognak állítólag az, hogy anno a bsd-sek implementálták így, az ietf-esek meg dokumentálták úgy, aztán rájöttek, hogy az rfc szerint készült progik csak nem beszélgetnek a bsd-s progikkal, erre aztán a kavarodást maximalizálandó bevezették az új kódot, ami kiváló ötlet volt, ugyanis minden alkalmazás a régi kódot használta, csak a bsd-sek az újnak a szemantikájával, így aztán mindenki írhatta át a cuccát: a bsd-ben a kódot, a többiek meg az értelmezést :).
De mivel a kompatibilitás jegyében a régi kódot visszavonni nem lehetett, mind a mai napig érvényben van, így mindenki lekódolja mindkettőt, és Murphy törvényei szerint háromból legalább kettő fordítva, így aztán az eredmény ipari mértékű anyázás egy soha-nem-használt kódrészlet fölött :). Derék, nemde?