I still do not recreate the problem. ^9999 dates are handled in our Koha::DateUtils module, take a look at:
223 # FIXME: see bug 13242 => no TZ for dates 'infinite' 224 if ( $dt->ymd !~ /^9999/ ) { 225 my $tz = $dateonly ? DateTime::TimeZone->new(name => 'floating') : C4::Context->tz; 226 $dt->set_time_zone( $tz ); 227 } Well there is a fixme, but basically it says that if the date is from 9999 we should use floating dates to avoid long processing when comparing dates. Take a look at 12669, 13242 and https://metacpan.org/pod/DateTime#Determining-the-Local-Time-Zone-Can-Be-Slow I guess there is a use of DateTime using the tz somewhere in the code. On Thu, 18 May 2017 at 17:22 Michael Kuhn <m...@adminkuhn.ch> wrote: > Hi > > We're running a new host with Debian GNU/Linux 8 and Koha 16.11.04. > > On 13 April I first wrote that sometimea when trying to login into the > Koha OPAC it takes more than 30 seconds until the login process finally > comes to an end, while the process "opac-user.pl" was eating up 99% of > the CPU. > > Some of you have kindly given my some hints but everything I tried was > of no avail: logging mySQL slow queries, iotop, strace -c -p PID, > tcpdump, checking logs (plack-error.log, opac-error.log etc etc), > executing various time measurements of the Perl scripts, deactivating > other programs (like Plack, EZproxy etc), enabling debugging for Plack, > etc etc > > Eventually I executed "strace -t -s 1024 -p PID" and tried to understand > the output. I doubt I did but some lines gave me the idea the problem > was connected with the card expiry date. The user data were migrated > from another ILS which contained a card expiry date of 9999-12-31 for > every user - I manually changed this to 2030-12-31 via SQL and all of a > sudden the login process was quick as experienced elsewhere. So the > problem feels like SOLVED by a workaround, at least in our Koha instance! > > But meanwhile we have found out the following: > > 1. 9999-12-31 is a valid date accepted by MySQL (see > https://dev.mysql.com/doc/refman/5.5/en/datetime.html) > > 2. The newly configured patron categories in our Koha instance all have > an enrollment period of 999 months (strangely it's not possible to > choose a higher number). > > 3. The migrated user data was imported via Koha menu "Tools > Patrons > and circulation > Import patrons". NO ERROR occurred and all the data > (including the date 9999-12-31) was correctly written into table > "borrowers". > > 4. In Koha menu "Patrons > New patron" when a new patron is added with > expiry date "31.12.9999" this is accepted WITHOUT ERROR. (the local Koha > system preference "datetime" is set to "dd.mm.yyyy") > > 5. Trying to login into the Koha OPAC will immediately lead to described > problem with the delayed login. > > 6. I tried step 4 on my own demo installation of Koha 16.11.00 with > expiry date "31/12/9999" - there a dialogue appears saying "Invalid year > entered in field dateexpiry". There is only a button "OK" - I clicked > that and then saved the user data. This worked without further errors > and the date can be found in field "borrowers.dateexpiry" as > "9999-12-31". It seems rather strange to me that Koha should warn about > an "invalid year" (whatever that means) but accepting it nonetheless. > Trying to login with this user in the OPAC of my demo installation works > quick as expected. > > To me the behavior (described in steps 1-5) feels like a bug because if > date 9999-12-31 is accepted by the patron import tool and also by MySQL > then it shouldn't be necessary to change that date. (But it seems this > problem is only existing on our Koha instance) > > Also the behavior (described in step 6) feels at least like a minor bug > because if Koha warns of an "invalid year" it should 1) be more explicit > (what exactly is invalid about the year?) and especially it shouldn't > allow to save that "invalid" year. > > What do you think of this? > > Best wishes: Michael > -- > Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis > Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz > T 0041 (0)61 261 55 61 <+41%2061%20261%2055%2061> · E m...@adminkuhn.ch · > W www.adminkuhn.ch > _______________________________________________ > Koha mailing list http://koha-community.org > Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha