How a software bug brought us into the history of the USSR
On the corporate portal of one of our customers, some users’ birthdays were not displayed correctly in their profiles – the page showed the date before the correct one. Our developers found out that the reason for this error was hidden deep in history.
First, the team checked the backend and made sure that the incoming data was correct. We analyzed the logs of interaction between user browsers and the site - turned out that the bug is reproduced only in Safari on Apple devices. And a date of birth was correct, only if a user entered the portal from another device and browser, for example, from Google Chrome on their computer.
Further, the team began to iterate over different periods, gradually shortening the time intervals in order to understand which date our bug is associated with. It turned out that the problem revolves around June 1930 - this is where the timing outage occurs (again, only in Safari). They tried to figure out what was special on June 21, 1930, and they dug up that on that day in the Soviet Union the time was shifted one hour ahead. Google Chrome handles this situation correctly, but Safari does not.
Another matter is the format of a variable that conveys this time. The format counts the number of milliseconds from time zero that’s set on January 1, 1970. Google Chrome processes the date June 21 as follows: from 11:59 pm to 1 am it costs 1000 milliseconds (i.e. 1 second), that is, this time "disappears". Safari believes that this time is there, because it does not know that the clock was translated in the USSR.
The team has reported this bug to the Apple Feedback Assistant and is awaiting a response. And the portal will receive its own patch with the next release.
P.S. During the investigation, the developers drew attention to another interesting fact. Users have a feature that allows them to only display the day and month of birth without a year. And it turned out that if the user selects such a setting, then the value "4 AD" is transmitted from the backend. Why?
It turned out that at first, one was set as the simplest default value. But then a bug appeared in the search - it did not find people with birthdays on February 29th. The used time storage structure does not allow to create an instance from February 29 in a non-leap year. Therefore, the first leap year in our era was prescribed in the code, and everything worked.