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