On the corporate portal of one of our customers, some users in their profile did not display the date of birth correctly - instead of the required day, the previous one was shown. 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 data is coming in correctly. We analyzed the logs of interaction of user browsers with the site - it turned out that the bug is reproduced only in Safari on Apple devices. And when users say that the date of birth is displayed correctly, they enter 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, and only in Safari. They began to figure out further what happened on June 21, 1930, and 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 feature in the format of a variable that conveys this time. The format counts the number of milliseconds from time zero - the stamp is on January 1, 1970. Google Chrome handles the date June 21 as follows: from 11:59 pm to 1 am it costs 1000 milliseconds (which is equal to 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.
PS During the investigation, the developers drew attention to another interesting fact. Users have a feature that allows you to display on the portal only 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. It was possible to establish why the creators of the portal chose this date only at the very end.
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.