I think it's more in the spirit of the article to say, forget timezones, use UTC millis everywhere. If the server doesn't speak in timezones, then you eliminated all bugs where the server mishandles timezones.
That's a flagrant example of "simple and wholly incorrect". If you don't store timezones, your future dates will eventually turn out incorrect when timezone offsets change e.g. create a meeting at 9AM local, store as UTC, country decides to not follow DST that year bam your reminder will ping an hour early or late.
Or a day off when the country decides to jump across the international date line (https://en.wikipedia.org/wiki/International_Date_Line#Samoan...).
Unless restrictions are specified I will assume we're talking about the general case, and for the general case it's just plain wrong.
There are very few applications that need to schedule events into the future, and that is literally the only situation where you have to worry about the timezone.
Btw, keeping the timezone is insufficient as well if you're building a calendar/scheduler. If the user changes the timezone after scheduling the event... do you keep to the old one and alert him whenever, or do you adjust? There are a lot of edge cases with schedulers -- yet as i said before, most applications don't schedule into the future. They're mostly just doing things right now or within the next few minutes and keeping a log of their actions.
> There are very few applications that need to schedule events into the future, and that is literally the only situation where you have to worry about the timezone.
My experience is the exact opposite: there are few applications which only store past dates, and in those said date is usually indicative/barely even relevant and could just as well be part of a freeform comment or removed entirely.
The solution isn't incorrect, it is modular.
So you provide an alarm clock which is works as neither a clock nor an alarm.
> The solution isn't incorrect, it is modular.
It's either not correct or not a solution, either way it's useless.
I also like how proponents of "simplicity at all cost" apparently assume/assert the composition of two systems is no more complex than either, and that there is no additional complexity to the composition layer.
Know your data, and most of your problems get easy.
Even "notify me in exactly 24 hours has its own complications. Leap seconds will screw up your day (as will the vague request of "exactly 24 hours").
Corner cases, the bane of simplicity everywhere.
How about another example? You're building an android application. Let's pretend there's an API in the latest version of Android that reduces a dozen lines of code down to one function call - ShinyNewMethod().
You can use that ShinyNewMethod() call. It's certainly simpler.
But the vast majority of android devices in use are not running the latest OS. So the NewShinyMethod(), while being simple, will cause your app to not work for them.
Hopefully the framework designers figured a way to have this auto-reverse engineer for older devices, but that's not always a guarantee.