Názory k článku
Další chyba v eDokladech, změna časového pásma telefonu o den posune datum narození
-
Argument, že je to v zahraničí použitelné až od nějakého data, je alibismus.
Jednak v EU jde cestovat na OP, tudíž to prostě musí fungovat správně a pak, jde evidentně o další důkaz toho, že celé tohle divadlo s elektonizaci Státní správy je pouze velká loupež pro Piráty a jejich sponzory.6. 3. 2024, 10:29 editováno autorem komentáře
-
Co se tyce cestovani na OP, tak tam to zatim neni mozne pouzivat, takze v tomto zatim neni problem. Problem by mohl treba byt, kdyby se v zahranici potkali 2 obcane CR a kontrolovali si tak elektronicky "doklad", ale hlavne prece neni nejmensi problem si casovou zonu v telefonu nastavit rucne a zneuzivat chybu primo v CR.
-
A jak přesně se tahle chyba dá zneužívat? Napadá mě maximálně den před osmnáctými narozeninami se o den postaršit a nechat si nalít alkohol když ještě nesmím, ale to teda nevidím jako moc tragédie.
Nebo kdybych náhodou měl jmenovce o den staršího / mladšího, tak bych se za něj teoreticky mohl vydávat, ale jen za předpokladu, že by si kontrolující nevšiml rozdílného bydliště a hlavně RČ - tak mi nepřijde moc užitečné.
-
Dobrý den,
dovolil bych si s Vámi nesouhlasit. Pro ověření osoby v registru obyvatel (ROB) je jedním z nejhlavnějších a nejčastěji používaných způsobů jméno, příjmení a datum narození. Pokud nejste v ROB, nikdo se s Vámi bavit nebude. A výmluvy, že máte datum špatně kvůli nějaké js knihovně asi na úřadech nezaberou.
Já bych dopad špatně zobrazeného data narození nepodceňoval. -
Tomu vasemu normalnimu cloveku se ta casova zona klidne prehodi uplne sama, nebo si ji prehodi nejaka aplikace kterou pouziva. Protoze ten normalni clovek vubec netusi, ze neco takoveho existuje, jeho tak maximalne zajima, jestli ty cibule zobrazuji spravne. A protoze ty cibule opet nejsou nic jineho nez aplikace, tak muzou pouzivat vlastni nastaveni casove zony, jine nez system.
-
ok, chyba s časovým pásmem, najde se o opraví, nic se neděje, vlastně v pořádku.
Co mě ale opravdu hodně zaráží a děsí je vlastně stav, kdy se data interpretují na klientovi a tam se zobrazují podle nastavení daného zařízení. Jak v takovém případě dokáže někdo garantovat, že ty data jsou věrohodná a správná? Tohle je přece špatně, aplikace/systém si musí být silně jistý, že se data nejenom do zařízení dostala správně, ale že také shodná data jsou zobrazena a do zobrazení nezasáhla třetí strana.
Posílat data v jsonu a interpretovat javascriptem na klientovi je pro mě noční můra.
-
člověk by řekl, že těm lidem chybí vzdělání, ale když jsem studoval, tak nás jeden profesor v teorii databází vyhazoval od zkoušky, když jsme chtěli IČO uložit jako varchar.
V praxi nad těmito věcmi sedí datových architekt a dává palec na tyhle implementace. Uložit datum narození jako datetime nebo date je většinou hrubka.
-
Tak měl by to být ideálně timestamp. :-D Věci jako datum (bez času a časové zóny) jsou akorát komplikace. Protože reálně když se narodím 2. 1. v jednu ráno, tak v Americe je ještě 1. 1. Když pak pojedu do USA, mám tvrdit, že jsem se narodil prvního nebo druhého?
Nemyslím to výše úplně vážně, jen chci ukázat, že některé naše zažité věci nedávají tak úplně smysl v jiném prostředí.
-
Samozřejmě, že má. Bude to ISO8601 s časem 00:00 a CZ timezónou, aby se to správně zobrazilo. Jinak to ukládat nejde. Pokud to bude Unix timestamp, tak sice super, ale TZ není implicitní a klient bude muset mít hardcoded CZ TZ. String do API neberu, nejsme v roce 1995.
6. 3. 2024, 20:44 editováno autorem komentáře
-
Jiste, krasna ukazka te naproste tuposti. Ten udaj je ZAKONEM definovany jako DATUM. Casovy udaj u nej vubec byt NESMI! A je to FIXNI STATICKY udaj, ktery se NIKDY nijak nemeni.
Je to presne totez jako zminene IC. To je idendifikator, nikoli cislo. A presne proto je snim treba nakladat uplne jinak nez s cislem.
-
nj. ale to je stejně špatně, TZ se občas aktualizují a nejsi schopný zajistit, že klient bude mít správnou databázi.
Hlavně třeba datum narození se musí zobrazovat v časové zóně, která byla v momentě narození a podle zóny, která je zrovna dneska.
Tohle je celé špatně. Datum narození (a další údaje) jsou string a jakákoliv práce s nimi je nežádoucí. Pokud je potřeba řešit zobrazení v lokálním formátu, za správný převod by měl být odpovědný backend.
-
TZ se nikdy nebude aktualizovat zpětně a to všechno řeší knihovna podle data, co tam je. Ten klient a jeho knihovnu máš pod kontrolou. Datum není string, a správně bude jako ISO8601 s TZ, v JS to řeší třeba knihovna moment.js. Všechno to bude OK v komputerovém formátu a klient si z toho vytáhne den podle České TZ, co tenkrát platila. A můžeš nad tím úplně klidně i počítat.
-
a pak ti tam někdo přidá datum platnosti dokladu nebo to podepíše certifikátem. Ne, musíš vždy pracovat s aktuální verzí tzdata. Ta databáze sama obsahuje historii všech změn, žádné snapshotování k datu není potřeba.
ISO8601 není string? A jak ho prosímtě zapisuješ?
Zrovna moment.js, víš, že zrovna tahle knihovna je odpovědná tenhle bug v eDokladech? A že zrovna tahle knihovna má lehké problémy s prací s TZ? Viz spousta jejich issues.
Základní registry u nás neobsahují časovou zónu k datu narození. Máme štěstí, že jsme malí, ale i tak tam vznikají problémy a chyby. Kdyby to z nich šlo jako ISO8601, bylo by to skvělé, bohužel to je občas větší zveřina než by člověk čekal.
-
Bohužel, podobné chyby se daly a dají čekat dál. V čem je ten problém - kéž by tedy jenom ta aplikace eDoklady jenom a pouze natvrdo zobrazovala ty informace které jsou v klasické občance. .
Jenomže, a autoři se tím dokonce chlubí, ona ta aplikace má ty údaje nikoliv jen zobrazit ale i sama interně vyhodnocovat a zobrazit pouze transformovaný výsledek.
Jako klasický příklad - budete chtít nakupovat alkohol nebo cigarety - musíte prokázat věk 18 a víc. O tom už se psalo, že pro tento požadavek ta apka neukáže ani to datum narození, ale jen info "ano" (je starší než 18) nebo "ne".
Takže si to ta apka musí interně převést na potřebný typ Date, Time , a porovnat ho se současnými hodnotami . Ale potom ejhle - do toho nějaká časová pásma, do toho třeba nějakej letní čas (který politici rádi čas od času mění),. a výsledkem budou hausnumera, než na to někdo příjde a opraví.. (a ty statisíce lidí si tu apku aj ta svoje data) stáhnou znova. -
"5.6.1830"
Toto je u nas bezne pouzivany format data. Znova zduraznuji, ze se nezivim jako programator.
Predpokladam, ze presne takto vyleze z nejakeho registru. year(getdate()) - cast(right(datumnarozeni,4) as int) ... zazracna technologie, ze? A pokud je to mene nez 17, nemusim vubec pokracovat ze? A jisteze existuje 150 jinych lepsich postupu, zcela umyslne prezentuji ten uplne nejtupejsi. V zadnem pripaden nebudu resit nejaky cas, natoz nejakou casovou zonu.
Jenze oni ti nactilety narozdil od nekterych tupi nejsou, takze si bud reknou nekomu z kolemjdoucich at jim to koupi, nebo se obslouzi ze zasob svych rodicu.
-
ne tak docela. Ono se totiž pracuje s datem narození a ne časem, takže datum 14. 4. 1981 se v programu používá jako 14. 4. 1981 00:00:00 v naší časové zóně, tu to převedlo na lokální časovou zónu a zobrazilo včerejšek.
Co je ale důležité, v právní pořádku datum narození se nepřevádí na časovou zónu a zůstává stejný ať jsem v USA nebo ČR. Upřednostňuje se snadná kontrola nad přesností. Pokud mám v pase datum narození 14. 4. 1981 v žádném případě nemůže elektronická občanka tvrdit 13.4.1981, to je principálně špatně a tak se s tím nemůže pracovat.
Datum narození je úřední údaj (identifikátor) a nemohu si ho měnit dle libosti, on i ten přepočet má svá pravidla.
-
Ono je pro mnohé nepochopitelné, že
datum narození
není fakticky datum (datetime), dokoncerodné číslo
není číslo...
Nemá smysl bádat nad nějakou časovou zónou v místě a čase narození, přepočítávat to na aktuální... Chyba je už v tom, že se ten program snaží zpracovávat jako časový údaj.
Mimochodem: ten údaj je čistě úřední, takže pokud se narodí jedno z dvojčat před půlnocí a druhé po půlnoci, budou mít pravděpodobně stejně obě stejné datum narození.
A na oslavě osmnáctin by člověku neměli prodat alkohol, protože osmnáct mu bude až po půlnoci, tedy o den později. (Dokonce vím o případu, kdy se řešilo, zda měl šestnáctiletý mladík sex se svou přítelkyní v den jejích patnáctých narozenin, nebo to bylo až po půlnoci...) -
není fakticky datum (datetime)
Datum není datetime. Jsou tři různé údaje – datum, čas a datum+čas. Čas (i ve spojení s datem) navíc může být uvádět s různou přesností. A všechny tři typy údajů jsou vždy vztažené k nějaké časové zóně. Pak je ještě čtvrtý údaj – trvání – který se ve spoustě případů zapisuje také jako čas, aby to bylo dostatečně matoucí.pokud se narodí jedno z dvojčat před půlnocí a druhé po půlnoci, budou mít pravděpodobně stejně obě stejné datum narození
Ne, nebudou.A na oslavě osmnáctin by člověku neměli prodat alkohol, protože osmnáct mu bude až po půlnoci
Ne, osmnáct je mu v den osmnáctých narozenin, tedy v den, který se označením shoduje s datem narození. Akorát lidé narození 29. 2. to mají mimo přestupné roky až o den později. -
Z těch typů to v podstatě není ani jedno, právě proto, že se k žádné časové zóně neukotvuje. Kdo se narodil 8. března, bude tam mít 8. března, i když v Japonsku bylo devátého nebo na Aljašce sedmého. Není to "8. března 2024 +01:00".
K těm dvojčatům jsem se vyjádřil výše.
Možná Vám to tak nepřipadá, ale pravdu mám já. ;oD
Osmnáct je člověku opravdu až den po narozeninách. Je to právě proto, že nikde není čas narození, takže teoreticky se mohl narodit ve 23:59 - a tedy mu do té doby ještě osmnáct není.
Souhlasím, že je to v podstatě hloupost, a že v praxi na tom nikdo obvykle nebazíruje.Ten případ šestnáctiletého mladíka a patnáctileté slečny by bez
bdělé občanky
, která prostě musela otravovat sociálku a následně policii, taky nikdo neřešil. Já se k tomu nachomejtl jen jako svědek, že mladík byl ještě po 20. hodině na kroužku programování a tedy je nepravděpodobné, že by se stačil k něčemu dobrat před půlnocí. Nakonec ho zachránilo, žebdělá občanka
určovala čas podle pořadů v TV Nova, které ale reálně začínaly o dobrých 10 minut později, takže od chvíle, kdy byl spatřen, jak chytá klíče před domem, do půlnoci, bylo tak málo času, že by to i s vybíháním schodů a nějakourychlou milostnou předehrou
reálně nestíhal.
Celé to bylo totálně absurdní. ;oD8. 3. 2024, 16:55 editováno autorem komentáře
-
Datum i čas se vždycky interpretují k nějaké časové zóně. Problémy nastávají tehdy, když se zvolí špatná časová zóna.
Pravdu s osmnáctinami nemáte. Právě proto, že se neuvažuje čas narození, ale jenom den. Když se dítě narodí 8. 3. 2024, bude mu 9. 3. 2024 jeden den, 8. 3. 2025 mu bude jeden rok, a 8. 3. 2024 mu bude osmnáct let. Bez ohledu na to, v kolik hodin se narodilo.
-
Tak to (s těmi narozeninami) zkuste vzít od začátku, od toho narození: miminu je jeden den až druhý den. Stejně tak mu po celý první rok je "méně než rok", protože se to počítá od nuly.
Když počítáte na dny, třeba lhůty, tak ten koncový den je součástí té lhůty. Tedy: pokud máte něco udělatdo 4. března
, úplně stačí, když to bude až ten poslední den. A přesně tak to platí pro ochranu před alkoholem (do 18 let) či sexem (do 15 let) - i ten poslední den, v den narozenin, ještě nesmíte.
Nicméně je zajímavé, že volit v den 18. narozenin můžete - protože ten je na začátku té lhůty a tedy se započítává. ;o)
Jenže tohle je opravdu jen teorie, kterou v praxi téměř nikdo neřeší - v podstatě dle hesla:kde není žalobce, není ani soudce
. ;o) -
Ne, nepočítá se to od nuly. Až do prvních narozenin běží první rok života dítěte, ne nultý. Prvními narozeninami završí první rok života a od dalšího dne tedy začne druhý rok života. Píšete správně, že miminu je jeden den druhý den po narození – ale hned od půlnoci toho dne. Počítá se to na celé dny a den začíná hned půlnocí.
Ze zákona je člověk zletilý od dovršení věku 18 let, to znamená od dne 18. narozenin, tj. ode dne, který se označením shoduje s dnem narození. (Výjimka je jen u lidí narozených 29. února, ti dovrší 18 let až 1. 3., pokud není přestupný rok.)
Volební právo je určené zletilostí, takže pokud 18. narozeniny připadají alespoň na poslední den voleb, dotyčný může volit (a může volit kterýkoli den voleb). Ochrana před alkoholem je opět určená tak, že se alkohol nesmí podávat osobě mladší 18 let. Takže v den 18. narozenin už se alkohol může podávat. Znásilnění má vyšší sazbu také v případě dítěte mladšího 15 let, takže opět, v den 15. narozenin už je ta ochrana stejná, jako mezi 15 a 18 lety.
Všechny tři věci totiž nejsou určeny jako lhůty, ale je to určeno věkem. A věk se počítá jako dovršení určeného počtu let života, přičemž se to počítá od data narození (ne od data a času).
Celé je to dané právě tím, že rozhodující je den narození, z hlediska práva se to nerozlišuje detailněji na hodiny, minuty, sekundy. A v právu když se něco počítá od nějakého dne, počítá se to od začátku dne. Tj. pokud se někdo narodí 11. 3. 2024 ve 23:55, pořád má datum narození 11. 3. 2024, první den jeho života je 11. 3. 2024 a první den života dovrší před 12. 3. 2024 0:00:00. Je to paradoxní, že první den jeho života může trvat jen pět minut, nebo i jen minutu, ale je to tak – a je to tím, že při počítání na dny nebo delší období se počítá od začátku dne, i když víme, že událost, od které se to počítá, nastala reálně až v průběhu dne.
-
Ciste teoreticky zakon hovori o zakazu osobam mladsim 18 let, clovek narozeny 11. 3. 2006 ve 13.00 je v dobe psani prispevku sice uz plnolety (plnoletost je definovana dnem narozeni), ale stale mladsi 18 let. Alkohol mu lze beztrestne prodat az za pul hodiny.
V praxi to asi nikdo nikdy nebude resit, ale jedinny bezpecny zpusob, jak na zaklade dat z dokladu, kde cas uveden neni, docilit, ze omylem neprodam alkohol o par minut mladsimu, je pockat do druheho dne. -
tumis: Ne, není to tak. Jak jsem psal, věk se počítá z data narození, ne z data a času narození. Z hlediska zákona je totiž podstatný údaj jenom datum narození – to, že se někde eviduje i čas narození je jakýsi bonus navíc, ale zákony s ním nepočítají. Proto máte také v občance jen datum narození. Tj. pokud se člověk narodil 11. 3. 2006, je možné mu beztrestně nalévat alkohol už od dnešní půlnoci, tj. od 11. 3. 2024 0:00:00 CET.
-
Je tam proste "mladsim 18 let" nic o tom, ze pro ucely zakona se predpoklada cas porodu 0:00:00. Clovek narozeny v poledne je pul dne mladsi. Pokud bychom si to svevolne vykladali takto zjednodusene, tak bychom mohli dojit k zaveru, ze tomu cloveku je 18 let uz 1.1. i kdyby byl narozen treba az v prosinci. Zakon to definuje v letech a par dni nebo mesicu prece nehraje roli ;-)
-
Ne, podle zákona se nepředpokládá čas porodu o půlnoci. Podle zákona se věk počítá od data narození. Toť vše. Takže si stačí spočítat, kdy se dovrší 18 let od 11. 3. 2006. A to se dovrší dovršením či uplynutím 10. 3. 2024, tedy jakmile je 11. 3. 2024, člověku narozenému 11. 3. 2006 je 18 let. Takhle (to, co máme za přirozené) se podle českého práva počítá čas. Pouze pokud je něco určeno kratší jednotkou, než je den, počítáte se podle přesného času. Pokud je použita jednotka den nebo delší, čas se nebere v úvahu a začátek se počítá na začátku dne (tedy o půlnoci) a konec na konci dne (tedy těsně před půlnocí).
-
V tom zakone neni zadny takovy predpoklad vyjadren. V jinych zakonech je navic explicitne zminovan den dosazeni veku 18 let, tudiz je zrejme, ze se nepredpoklada, ze je to samo sebou. Tady o dni neni rec a logicky by se tedy melo jednat o presny vek a cloveku, ktery zacina oslavu 18. narozenin pripitkem v osm vecer, ale je narozen az o pul devate, by nikdo nemel nalit :-)
-
Ano, jedná se o přesný věk 18 let. Protože rok je větší jednotka, než den, nepočítá se to od přesného okamžiku, ale po dnech. A protože se u osob neeviduje přesný čas na rození, ale jen datum narození, nemůže se nic odvozovat od času narození, ale jen od data.
Jak se počítá čas máte popsáno v občanském zákoníku. Podle zákona o evidenci obyvatel se eviduje datum narození, ne datum a čas.
Pokud se podle vás podle nějakého zákona eviduje čas narození osoby, uveďte, podle kterého zákona. Pokud podle vás věk 18 let není definován v letech, ale v něčem menším, než den, třeba v hodinách nebo minutách, uveďte, podle jakého zákona.
