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/