Re: Patron Birthdate

[Martha Driscoll <driscoll@xxxxxxxxxx>]

On Mon, 17 Mar 2003, David Jones wrote:

> One question I have for you though: when you had Innovative setup the
> field for you did you have it set to display mm-dd-yy or mm-dd-yyyy? Are
> you sure the dates between 01 and 37 are really 1901-1937 and not
> 2001-2037?

The date was setup in the format mm-dd-yyyy.  I have been putting the date 
in with that format (actually I have an expect script that is moving the 
data from the var field to the fixed field).  The year '1901' etc. goes in 
as 1901.

> Here's an alternate theory:
> 
> The editor won't let you enter any dates that have 2038 as the year in
> places like the expiration date. Even those dates in 2038 that are prior
> to the end of time (Tue, 19 Jan 2038 03:14:08 GMT). Is that true for the
> birthdate as well?

The birthdate works a little differently from the expiration date.  You
can enter dates prior to 01-01-1970, and you can enter dates through 2038
up to 12-31-2038.  The system refuses to store anything beyond 2038 and
before 1900 and tells you the date is invalid.  The strange thing about 
1932 is you never get an error message when you store the record, and 
create list sorts these dates correctly (they fall between 1931 and 1933) 
so there is something in that field even though it appears to be blank.

> What if the editor control for the birthdate is somehow combining these
> and not allowing you to enter dates that would be 38 years before the
> start of time (Thu, 01 Jan 1970 00:00:00 GMT), but is safely allowing
> you to enter any other date between the beginning of time (Fri, 13 Dec
> 1901 20:45:52 GMT) and the start of time?

Yes. I think there is some attempt at making the system store a date that
falls outside the usual UNIX tools for dealing with dates and something
went wrong.  Innovative has re-opened the call for us so I hope they will
resolve this.  The help desk looks very silly explaining that the system
cannot store 1932, and I'm going to look even sillier telling 500
librarians that they have to change the birth year of patrons from 1932 to
1933.  This probably hasn't been a problem in the past since birthdate is
a new var field, but I think it points out the need for a robust database
to be managing this data.  We got through Y2K, but now we have Y38 to look
forward too!

--
Martha Driscoll, Systems Manager
North of Boston Library Exchange (NOBLE)
driscoll@xxxxxxxxxx
Ph: 978-777-8844  Fax: 978-750-8472