Right, but you don't need "smart people to converge on" an agreement as to whether or not the 2nd of February is a Thursday. That would seem to be pretty well-defined.
Though, it’s interesting to note that once when I took a date picker component and attempted to morph it into a full-blown MacOS calendar, with calendar appointments that slot into different time slots and don’t overlap, I found that that is an NP-Hard bin packing problem.
...how would one even define a complexity class for date picker components?
Assuming a timezone mismatch, it wouldn't always show up because the date would have to cross a midnight boundary for the days to be different. Even if we assumed the servers used Malaysia time rather than UTC, that leaves 8 hours in a day where North American travelers could see the right day.
They got it wrong by 2 days.
More seriously, that would be a Y2K bug that took close to 20 years to discover, which I think is basically impossible.
Yeah, but the situation is worse than that. Weeks boundaries are influenced by a locale. What is the first day of the week? Sunday? Monday? I know that in russia a week starts with a monday. I know also that in en locales it is not the case, I was never able to understand english calendars, so the very first thing I do is fixing locale to see a "proper" calendar which I can understand.
Notice that there are no hints where is sunday and where is monday, you make a decision what is what based on data layout in a two-dimensional grid. For example, I read the screenshot in the tweet as Feb 2 is a Friday, not Thursday.
This leads me to a hypothesis what happened with AirAsia. They messed up locale dependant calculation of a week boundary. Like they added 1 instead of subtracting it, or maybe they applied the locale dependant shift of a week bondary twice, or made some other software bug like that.
Sure it's "defined", but it's full of hacks to deal with whims of fancy.
Even the day of the week calculation is borderline moronic.