I was getting the off-by-one day issue when testing this as well. I tracked it (for starters, anyway) to how we were extracting dates from libdbi. Like JS, libdbi appears to assume that if a date has no timezone, it's GMT. So, we were reading a GMT date, then translating into local time, thus shifting it back by a day.
I've pushed a branch that contains the SQL changes Mike posted (plus one more that cropped up) and another commit changing how we read dates (without times) in oils_sql.c and oils_execsql.c. The end result being that the date stored in the DB is the date returned by cstore. It's at least a first step.
The Dojo patron editor and various interfaces in the browser client are showing the correct date for me w/ patrons whose DoB crosses the daylight savings boundary.
Incidentally, open-ils.storage is returning the correct date as well when called from srfsh without modification.
I was getting the off-by-one day issue when testing this as well. I tracked it (for starters, anyway) to how we were extracting dates from libdbi. Like JS, libdbi appears to assume that if a date has no timezone, it's GMT. So, we were reading a GMT date, then translating into local time, thus shifting it back by a day.
I've pushed a branch that contains the SQL changes Mike posted (plus one more that cropped up) and another commit changing how we read dates (without times) in oils_sql.c and oils_execsql.c. The end result being that the date stored in the DB is the date returned by cstore. It's at least a first step.
The Dojo patron editor and various interfaces in the browser client are showing the correct date for me w/ patrons whose DoB crosses the daylight savings boundary.
Incidentally, open-ils.storage is returning the correct date as well when called from srfsh without modification.
http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ berick/ lp838525- dob-as- date