Comment 3 for bug 838525

A bit more background here, as well...

"Alright, this is what we know. Older versions of the staff client didn't handle timezones very well. There are a lot of moving parts and changesets here, and it's probably not feasible to patch things piecemeal. The changesets we involved ourselves previously in this ticket would affect the newer patron editor, but not the one Indiana is actually using (nor would it help with the patron summary sidebar). In the past, bad timezone handling may not have mattered because of the actual timezone being used when sending dates over the wire. However, now we're seeing cases like

1960-07-11T00:00:00-0400 being represented as 1960-07-10T23:00:00-0500, which while mathematically correct, runs afoul of the bugs in the older code (where dates are, for example, treated as text strings and truncated to the first 10 characters).

The dates and timezones on the servers involved all seem correct, and I don't know why Indiana's older brick presents the problem dates one way and the newer bricks present them another.

So barring upgrades, or any insight on middle layer/server timezone handling, one kludge I can think of would be to set a trigger on the actor.usr table to intercept updates to the date of birth field, and change the time component of such dates to mid-day. Such a timestamp would be resistant to change of day rollovers based on time zone."

With that, we then created the trigger attached here, though this may not be needed on 2.x. It's also possible we have some misconfiguration so that the database is seeing the wrong timezone.