[narsil]

Well it's likely the client/server time-zone mismatch was the cause here. It could be that everyone at AirAsia, or even the majority of passengers, saw the right dates, and this edge case was simply not considered.

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.

[EpicEng]

Time zone shenanigans or not, it has nothing to do with UX. 2/2 is not on Thursday, anywhere in the world, period. This is simply an obvious bug and a lack of customer service, not some UI failing because UI is "really hard".

[felipelemos]

Are you aware that dates does not get influenced by timezones, right? And not only that: Thursday was January 31. Friday was February 1. Saturday was February 2.

They got it wrong by 2 days.

[foobar1962]

Feb 2 0019 is Thursday. Off by 2000 years.

[ordu]

> Are you aware that dates does not get influenced by timezones, right?

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.