Vlákno názorů k článku
Další chyba v eDokladech, změna časového pásma telefonu o den posune datum narození od Uncaught ReferenceError: - ok, chyba s časovým pásmem, najde se o...

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.

Datum narození je datum, ne časový údaj, timezone v něm nemá co dělat.

To by me zajimalo, jak se "interpretuje" ... string. Spis tu aplikaci psal uplne stejny tupec jako DiPSy.

Protoze ja, neprogramator, kdyz vemu string, tak vytisknu string, a nic s nim nedelam. Tudiz to bude presne stejna sada znaku zcela bez ohledu na to, kolik je zrovna hodin.

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.

Budete pouzivat datum ktere je vztazene k mistu narozeni -
coz je oficialni udaj vetsinou parovany v dokumentech s datem. A to i u zaostalych zemi.
Obavam se ze superpozice narozeni u cloveka zatim neni prokazana :-)

7. 3. 2024, 05:47 editováno autorem komentáře

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.

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

toto: Já se ale narodila v cca 18:15 a ne v 00:00. A spousta lidí neví přesný čas narození. A hlavně čas v datu narození nemá co dělat - rodný list čas neobsahuje.

To je klasický problém, kdy se, řečeno jazykem Kotlinu, hodnota která by měla mít typ LocalDate reprezentuje typem Instant. JavaScript nemá nic jako LocalDate - tam by asi bylo nejlepší, aby to byl řetězec.

Ani jedna ze stran ta data neupravuje, jen interpretují statický string, který reprezentuje tu občanku. V appce to možná posunulo zobrazené datum o den, ale občanka zůstala bez změny.

Coz ale zjevne autori nechapou. A podobne kravoviny jsou k nalezeni v tisicich aplikaci. Jako treba pole pro datum, ktere je ale datetime, takze kdyz pak clovek treba hleda, tak to dopadne tak, ze prece datum = yyyy/mm/dd === ... 00:00 ... tudiz zadny vysledek.

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.

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

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.

No prave, a presne proto kdyz pridje nekdo s VS a SS, tak si vyberu toho druheho, ten jeste nestacil uplne zblbnout.

JS s knihovnama umí timezony úplně v pohodě. To by tam ale museli ze serveru poslat tu českou a na klientovi to tak nechat.

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