Odpověď na názor

Proste si priznejme ze problematice zcela nerozumite ( ja take ne ). Proto pouziji specializovanou knihovnu a udaje z ni interpretuji volne - nehonim je pres omezenejsi datove typy.
Vlastni implementaci prace s casem udela jen naprosto nevzdelany prilis sebevedomy associate apprentice junior z pocitacoveho krouzku programovani neznaly problematiky.

Tady je takovy "kratsi" seznam z praxe na co musite pamatovat:
https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca
Knihovna za vas pamatuje i na edge cases ktere v tomto seznamu nejsou.

V praxi s cim jsem se posledni leta setkal:
- prestupy letni/zimni cas kazde pasmo jine a jindy
- zona nema zarovnanou 1h
- prestupna sekunda zbori dodavateli aplikaci
- americky format data nespravne implementuji i americani - viz. ta ohyzdnost formatu data v jazyce go
- progros ma 20 let stare definice zon a nepouziva standartni knihovny - zmena zony nastala driv nez release cyklus aplikace
- aplikace predpoklada ze cas na stroji je v lokalni zone v miste kde se vyviji