https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37952

--- Comment #7 from David Cook <dc...@prosentient.com.au> ---
Consider "dateofbirth" which is a "date" column in the borrowers and
deletedborrowers tables.

If my date of birth is 1970-01-01 09:00 in Australia/Sydney time, that's
actually 1969-12-31 22:00 UTC time.

If we just store 1970-01-01 and automatically translate it from UTC to
Australia/Sydney, then 1970-01-01 00:00 becomes 1970-01-02 11:00 which is a
different day. That's not going to work.

--

I suppose "dateofbirth" might be a special case where it could just always be
treated as local. For instance, your date of birth is on your government
identification. I'd say most authorities would treat your date of birth in
terms of the local timezone.

With "volumedate" in the "biblioitems" table it would probably be a floating
timezone since it would just refer to the date of publication relative to the
place of publication. For argument sake, I think we could probably interpret
this as local time though like "dateofbirth". 

But "dateexpiry" without a timezone would probably lead to subtle bugs for
things like ./misc/cronjobs/membership_expiry.pl, since the >= and <=
parameters are based off dt_from_string which will use UTC by default and
execute in the context of the backend system (keeping in mind that we can have
a variety of different timezones on a server for different Koha instances). Of
course, maybe that means that "dateexpiry" should actually be a DATETIME value
with 23:59 for the time component.

There are 97 "DATE" columns in Koha. We'd probably need to review every one of
them to avoid bugs.

-- 
You are receiving this mail because:
You are watching all bug changes.
_______________________________________________
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to