The cause is usually a JavaScript Date object used to store and render a date. When an exact time is not stored along with the Date, which would be expected in the case of a birthday, it will default to 00:00:00 UTC. When converted to a string, it will take the browser's local timezone into account, and given that most of us live west of UTC, it would convert 2020-07-29 00:00:00 UTC to, e.g., 2020-07-28 20:00:00 EDT. The browser will thus render July 28, even if the underlying data indicates July 29.

Technically the underlying database backend contains the correct date and would remain on the correct date as long as nothing is sent back. However, if the date displayed is also part of a user-editable field in a form, the D-1 date could be sent back by the browser even if the user didn't edit it. Depending on how this is processed, the wrong date could then replace the correct date in the backend.

We generally don't see this on websites developed here in the US, as this JavaScript quirk is usually spotted during development. We see it a lot on websites that exclusively serve areas east of UTC and don't expect to deal with timezone differences (or at least don't test for that). It's weird that UA fell victim to this as well; it makes you wonder where their website development team is located.