CodeOpinion

https://codeopinion.com/event-sourcing-example-explained-in-plain-engl… Derek Comartin does a great job explaining event sourcing on his site. I really like him for being able to easily explain fairly technical ideas like this. However, like others have said, this should be a tool reserved strategically for ideal situations, not a jackhammer for every task.

tzdata makes guesses (predictions) all the time -- every time in the future is a guess. There is no way to know that a government won't change DST dates, or even shift a country to a different timezone. Look at the whole Lebanon mess from earlier this year: If you had, at Mar 24 2023 10:00 UTC gone and created a meeting at 10AM Beirut on Mar 27th 2023 it would have been at 0800 UTC (based on the official Lebanon position that DST would not start until April 21st [0]), and you would have been wrong [1] Had you stored the datetime with location then you would have been fine. The tzdata community far know more about time than you do and make a good job at guessing what the time will be, but they still have to issue multiple updates each year due to changes from different governments. Take this update from 2021 when Fiji suspended DST for the following year https://mm.icann.org/pipermail/tz-announce/2021-October/000068.html "Assume for now that it will return next year" It's a guess. nobody in October 2021 could say for certain that Fiji would or would not have DST in 2023. This isn't controversial. Past dates can be problematic - especially from 50+ years ago (historical data may crop up which shows that a specific location had different UTC offset which means a historical update is needed), but for future dates all predictions of UTC offsets for geographic locations are a guess [2]. Hell you can't even store the tzdata location group (say Europe/London) because in…