[Bug 23079] New: Checkouts page broken because of problems with date calculation (TZAmerica/Sao_Paulo)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Bug ID: 23079 Summary: Checkouts page broken because of problems with date calculation (TZAmerica/Sao_Paulo) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: katrin.fischer@bsz-bw.de QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com Target Milestone: --- We keep having issues especially with the TZ America/Sao_Paulo in certain areas of Koha. The most recent error was the checkouts page showing "Internal server error" resolving to: Invalid local time for date in time zone: America/Sao_Paulo The date expiry of this patron was: 2019-12-03 Changing the date expiry date to be a day later (2019-12-04) fixed the issue. The patron currently has no checkouts. I am not sure yet if other settings factor into this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org Severity|normal |major --- Comment #1 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- I have no idea how to provide a global and quick fix for this. It will be a big problem for Brazilian libraries using Koha (are there?): % perl -MDateTime -e "DateTime->new(year => 2019, month => 12, day => 3, time_zone => 'America/Sao_Paulo')->subtract(days => 30);" Invalid local time for date in time zone: America/Sao_Paulo % perl -MDateTime -e "DateTime->new(year => 2019, month => 11, day => 3, time_zone => 'America/Sao_Paulo');" Invalid local time for date in time zone: America/Sao_Paulo -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #2 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- You specific issue could be fixed with: @ Patron.pm:625 @ sub is_going_to_expire { return 0 unless $delay; return 0 unless $self->dateexpiry; return 0 if $self->dateexpiry =~ '^9999'; - return 1 if dt_from_string( $self->dateexpiry )->subtract( days => $delay ) < dt_from_string->truncate( to => 'day' ); + return 1 + if dt_from_string( $self->dateexpiry, undef, 'floating')->subtract( days => $delay ) < + dt_from_string->truncate( to => 'day' ); return 0; } But it will not help much. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jonathan Druart from comment #1)
I have no idea how to provide a global and quick fix for this. It will be a big problem for Brazilian libraries using Koha (are there?):
We alone support 4 in this timezone. I was wondering because we don't see issues in other timezones so far and we got quite a few with the Goethe institute libraries. Can you explain the issue a bit? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #4 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Katrin Fischer from comment #3)
(In reply to Jonathan Druart from comment #1) Can you explain the issue a bit?
On Nov 3rd 2019, Brazil will skip from 00:00 to 1:00 (http://www.currenttimeonline.com/dst/dst.do?tz=America/Sao_Paulo), DateTime consider it as an invalid date. It is a problem when we are playing with dates without the time part (always 00:00). When we instantiate a DateTime (from dt_from_string) we are already handling this issue, and use the floating timezone (since bug 12669). The problem remains when we generate a DateTime then add or subtract a duration, which will result in an invalid date: DateTime->new(year => 2019, month => 12, day => 3, time_zone => 'America/Sao_Paulo')->subtract(days => 30); => Nov 3rd 2019, kaboom. I think we should replace all the occurrences of dt_from_string->subtract (or ->add) with dt_from_string(undef, undef, 'floating'), to use the floating timezone and avoid the error. Technical note: we must update the prototype of dt_from_string before, to send a hashref instead: dt_from_string({ timezone => 'floating'}); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #5 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 90939 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=90939&action=edit Bug 23079: Add tests -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #6 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 90940 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=90940&action=edit Bug 23079: Handle invalid timezones when adding/subtracting durations On Nov 3rd 2019, Brazil will skip from 00:00 to 1:00 (http://www.currenttimeonline.com/dst/dst.do?tz=America/Sao_Paulo), DateTime consider it as an invalid date. It is a problem when we are playing with dates without the time part (always 00:00). When we instantiate a DateTime (from dt_from_string) we are already handling this issue, and use the floating timezone (since bug 12669). The problem remains when we generate a DateTime then add or subtract a duration, which will result in an invalid date: DateTime->new(year => 2019, month => 12, day => 3, time_zone => 'America/Sao_Paulo')->subtract(days => 30); => Nov 3rd 2019, kaboom. We should replace all the problematic occurrences of dt_from_string->subtract (or ->add) with dt_from_string(undef, undef, 'floating'), to use the floating timezone and avoid the error. Actually there are not many of them, I have found only 3 that could produce real problems. The other occurrences are: - in tests => Not a big deal (for now) - called on a datetime, so it will explode if called at midnight 00:00:00 (and nobody should work at that time). Test plan: 0/ Define the timezone to 'America/Sao_Paulo' (in your koha-conf.xml file), restart_all 1/ Set a patron's expiry date to Dec 3rd 2019, and NotifyBorrowerDeparture to 30 (default value) 2/ See the checkouts page for this user => Without this patch you get "Invalid local time for date in time zone: America/Sao_Paulo" => With this patch apply the page displays correctly QA will review the 2 other occurrences. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |jonathan.druart@bugs.koha-c |ity.org |ommunity.org --- Comment #7 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Actually the situation is not as dramatic as I thought. Those patches should fix the problematic cases, and especially the one you reported, Katrin. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtompset@hotmail.com --- Comment #8 from M. Tompsett <mtompset@hotmail.com> --- (In reply to Jonathan Druart from comment #4)
I think we should replace all the occurrences of dt_from_string->subtract (or ->add) with dt_from_string(undef, undef, 'floating'), to use the floating timezone and avoid the error.
Personally, I prefer all dates in the DB were GMT, and all calculations were GMT, and then dates displayed were in local based on the user signed on. Sadly, that would be a massive undertaking. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #9 from M. Tompsett <mtompset@hotmail.com> --- Comment on attachment 90940 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=90940 Bug 23079: Handle invalid timezones when adding/subtracting durations Review of attachment 90940: --> (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=23079&attachment=90940) ----------------------------------------------------------------- ::: Koha/Patron.pm @@ +622,4 @@
return 0 unless $delay; return 0 unless $self->dateexpiry; return 0 if $self->dateexpiry =~ '^9999'; + return 1 if dt_from_string( $self->dateexpiry, undef, 'floating' )->subtract( days => $delay ) < dt_from_string(undef, undef, 'floating')->truncate( to => 'day' );
I'd prefer GMT. ::: acqui/duplicate_orders.pl @@ +74,4 @@
unless ( $input->param('from') ) { # Fill the form with year-1 + $from_placed_on->set_time_zone('floating')->subtract( years => 1 );
Why not: $from_placed_on->set_year($from_placed_on->year() - 1); -- no timezone needed. ::: acqui/histsearch.pl @@ +94,4 @@
my $to_placed_on = eval { dt_from_string( scalar $input->param('to') ) } || dt_from_string; unless ( $input->param('from') ) { # Fill the form with year-1 + $from_placed_on->set_time_zone('floating')->subtract( years => 1 );
Why not: $from_placed_on->set_year($from_placed_on->year() - 1); -- no timezone needed. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #10 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to M. Tompsett from comment #9)
Comment on attachment 90940 [details] [review] Bug 23079: Handle invalid timezones when adding/subtracting durations
Review of attachment 90940 [details] [review]: -----------------------------------------------------------------
::: Koha/Patron.pm @@ +622,4 @@
return 0 unless $delay; return 0 unless $self->dateexpiry; return 0 if $self->dateexpiry =~ '^9999'; + return 1 if dt_from_string( $self->dateexpiry, undef, 'floating' )->subtract( days => $delay ) < dt_from_string(undef, undef, 'floating')->truncate( to => 'day' );
I'd prefer GMT.
Why?
::: acqui/duplicate_orders.pl @@ +74,4 @@
unless ( $input->param('from') ) { # Fill the form with year-1 + $from_placed_on->set_time_zone('floating')->subtract( years => 1 );
Why not: $from_placed_on->set_year($from_placed_on->year() - 1); -- no timezone needed.
Hum? I do not understand how it will fix the problem. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #11 from M. Tompsett <mtompset@hotmail.com> --- (In reply to Jonathan Druart from comment #10)
(In reply to M. Tompsett from comment #9)
Comment on attachment 90940 [details] [review] [review] Bug 23079: Handle invalid timezones when adding/subtracting durations
Review of attachment 90940 [details] [review] [review]: -----------------------------------------------------------------
::: Koha/Patron.pm @@ +622,4 @@
return 0 unless $delay; return 0 unless $self->dateexpiry; return 0 if $self->dateexpiry =~ '^9999'; + return 1 if dt_from_string( $self->dateexpiry, undef, 'floating' )->subtract( days => $delay ) < dt_from_string(undef, undef, 'floating')->truncate( to => 'day' );
I'd prefer GMT.
Why?
https://metacpan.org/pod/DateTime#How-DateTime-Math-Works Nice long read of recommendations. Floating is fine if we don't care about leap days/seconds, but if we are subtracting days, then perhaps we do care? "If you can always use the floating or UTC time zones, you can skip ahead to "Leap Seconds and Date Math" " So, this uses floating, I'd prefer UTC. Floating is good if we don't care about partial days, but... "$dt->subtract( $duration_object ) A synonym of $dt->subtract_duration( $duration_object )." -- implying we care about partial days. "If you only care about the date (calendar) portion of a datetime, you should use either delta_md() or delta_days(), not subtract_datetime(). This will give predictable, unsurprising results, free from DST-related complications." In short, floating is perfectly okay if we don't care about partial days, do we?
::: acqui/duplicate_orders.pl @@ +74,4 @@
unless ( $input->param('from') ) { # Fill the form with year-1 + $from_placed_on->set_time_zone('floating')->subtract( years => 1 );
Why not: $from_placed_on->set_year($from_placed_on->year() - 1); -- no timezone needed.
Hum? I do not understand how it will fix the problem.
When timezones are involved weird and wonderful maths are necessary. Since we are just looking for last year, and the time in the current date is valid (otherwise it would have blown up sooner) merely changing just the year back one year avoids anything that might pass-through bizarre timezone stuff. Though, perhaps we care about that? If we care about partial days, then floating is wrong. If we don't, then floating is okay. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #12 from M. Tompsett <mtompset@hotmail.com> ---
Why not: $from_placed_on->set_year($from_placed_on->year() - 1); -- no timezone needed.
Hum? I do not understand how it will fix the problem.
"Do not use this method to do date math. Use the add() and subtract() methods instead." https://metacpan.org/pod/DateTime#%22Set%22-Methods -- Okay, bad suggestion. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #13 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- We are subtracting days, so to me floating is correct here. If you think we must use GMT because floating is problematic, could you provide an example? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Jonathan, thx for your work and input on this! I've tried signing off, but the tests don't pass for me: kohadev-koha@kohadevbox:/home/vagrant/kohaclone$ prove t/db_dependent/Koha/Patrons.t t/db_dependent/Koha/Patrons.t .. 8/40 # Failed test at t/db_dependent/Koha/Patrons.t line 275. # got: '' # expected: 'On invalid "is going to expire" date, the method should not crash with "Invalid local time for date in time zone"' # Looks like you failed 1 test of 9. # Failed test 'is_going_to_expire' # at t/db_dependent/Koha/Patrons.t line 280. Could you have a look? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #90939|0 |1 is obsolete| | --- Comment #15 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 92521 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=92521&action=edit Bug 23079: Add tests -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #90940|0 |1 is obsolete| | --- Comment #16 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 92525 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=92525&action=edit Bug 23079: Handle invalid timezones when adding/subtracting durations On Nov 3rd 2019, Brazil will skip from 00:00 to 1:00 (http://www.currenttimeonline.com/dst/dst.do?tz=America/Sao_Paulo), DateTime consider it as an invalid date. It is a problem when we are playing with dates without the time part (always 00:00). When we instantiate a DateTime (from dt_from_string) we are already handling this issue, and use the floating timezone (since bug 12669). The problem remains when we generate a DateTime then add or subtract a duration, which will result in an invalid date: DateTime->new(year => 2019, month => 12, day => 3, time_zone => 'America/Sao_Paulo')->subtract(days => 30); => Nov 3rd 2019, kaboom. We should replace all the problematic occurrences of dt_from_string->subtract (or ->add) with dt_from_string(undef, undef, 'floating'), to use the floating timezone and avoid the error. Actually there are not many of them, I have found only 3 that could produce real problems. The other occurrences are: - in tests => Not a big deal (for now) - called on a datetime, so it will explode if called at midnight 00:00:00 (and nobody should work at that time). Test plan: 0/ Define the timezone to 'America/Sao_Paulo' (in your koha-conf.xml file), restart_all 1/ Set a patron's expiry date to Dec 3rd 2019, and NotifyBorrowerDeparture to 30 (default value) 2/ See the checkouts page for this user => Without this patch you get "Invalid local time for date in time zone: America/Sao_Paulo" => With this patch apply the page displays correctly QA will review the 2 other occurrences. Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #92521|0 |1 is obsolete| | --- Comment #17 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Created attachment 92526 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=92526&action=edit Bug 23079: Add tests Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #92525|0 |1 is obsolete| | --- Comment #18 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 92552 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=92552&action=edit Bug 23079: Handle invalid timezones when adding/subtracting durations On Nov 3rd 2019, Brazil will skip from 00:00 to 1:00 (http://www.currenttimeonline.com/dst/dst.do?tz=America/Sao_Paulo), DateTime consider it as an invalid date. It is a problem when we are playing with dates without the time part (always 00:00). When we instantiate a DateTime (from dt_from_string) we are already handling this issue, and use the floating timezone (since bug 12669). The problem remains when we generate a DateTime then add or subtract a duration, which will result in an invalid date: DateTime->new(year => 2019, month => 12, day => 3, time_zone => 'America/Sao_Paulo')->subtract(days => 30); => Nov 3rd 2019, kaboom. We should replace all the problematic occurrences of dt_from_string->subtract (or ->add) with dt_from_string(undef, undef, 'floating'), to use the floating timezone and avoid the error. Actually there are not many of them, I have found only 3 that could produce real problems. The other occurrences are: - in tests => Not a big deal (for now) - called on a datetime, so it will explode if called at midnight 00:00:00 (and nobody should work at that time). Test plan: 0/ Define the timezone to 'America/Sao_Paulo' (in your koha-conf.xml file), restart_all 1/ Set a patron's expiry date to Dec 3rd 2019, and NotifyBorrowerDeparture to 30 (default value) 2/ See the checkouts page for this user => Without this patch you get "Invalid local time for date in time zone: America/Sao_Paulo" => With this patch apply the page displays correctly QA will review the 2 other occurrences. Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #92526|0 |1 is obsolete| | --- Comment #19 from Nick Clemens <nick@bywatersolutions.com> --- Created attachment 92553 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=92553&action=edit Bug 23079: Add tests Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to master Version(s)| |19.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #20 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Nice work! Pushed to master for 19.11.00 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Fridolin SOMERS <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to master |Pushed to stable Version(s)|19.11.00 |19.11.00,19.05.03 released in| | CC| |fridolin.somers@biblibre.co | |m --- Comment #21 from Fridolin SOMERS <fridolin.somers@biblibre.com> --- Pushed to 19.05.x for 19.05.04 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Jose Ricardo Quaglio <jose.quaglio@saobernardo.sp.gov.br> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jose.quaglio@saobernardo.sp | |.gov.br --- Comment #22 from Jose Ricardo Quaglio <jose.quaglio@saobernardo.sp.gov.br> --- Hello, I work at the public library of Sao Bernardo do Campo / Sao Paulo / Brazil. We have been using Koha since 2009, and we always have problems with the time zone. We currently use version 18 and have a homologation server with version 19, both with error. Today, 1/11/2019, we do not have "summer time". There is an error in the time zone of registering a new user, check out or renew materials. Error: "Internal Server Error" in "/cgi-bin/koha/members/memberentry.pl" When checking the log "plack-error": Wide character in print at /usr/share/perl5/CGI/Session/Driver/file.pm line 118. Wide character in print at /usr/share/perl5/CGI/Session/Driver/file.pm line 118. Invalid local time for date in time zone: America / Sao_Paulo Can someone help me? Tks, -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #23 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jose Ricardo Quaglio from comment #22)
Hello,
I work at the public library of Sao Bernardo do Campo / Sao Paulo / Brazil.
We have been using Koha since 2009, and we always have problems with the time zone.
We currently use version 18 and have a homologation server with version 19, both with error.
Today, 1/11/2019, we do not have "summer time".
There is an error in the time zone of registering a new user, check out or renew materials.
Error: "Internal Server Error" in "/cgi-bin/koha/members/memberentry.pl"
When checking the log "plack-error": Wide character in print at /usr/share/perl5/CGI/Session/Driver/file.pm line 118. Wide character in print at /usr/share/perl5/CGI/Session/Driver/file.pm line 118. Invalid local time for date in time zone: America / Sao_Paulo
Can someone help me?
Tks,
Hi Jose, there are no versions 18 and 19, (there are 18.05, 18.11, 19.05 - two a year and many bugfix releases between: 18.11.10...), you always need to give us the full version number as listed on the about page to make it possible for us to see if this should have been fixed by this patch or not. When you experience the problem again, try manually changing the date expiry by a bit to be able to work around it. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |liz@catalyst.net.nz, | |lucas@bywatersolutions.com --- Comment #24 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- @RMaints, please backport this one, even if a bit late for this year. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 --- Comment #25 from Jose Ricardo Quaglio <jose.quaglio@saobernardo.sp.gov.br> --- Katrin Fischer, We use version 18.11.03.000 and have a homologation server with version 19.05.04.000. We are doing this to work around the problem. This year the government did not apply "summer time". I noticed that in version 19.05.04 this bug was adjusted, but I think it was not thought in case the government did not implement this time. Tks, -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=29718 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Mason James <mtj@kohaaloha.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtj@kohaaloha.com --- Comment #26 from Mason James <mtj@kohaaloha.com> --- (In reply to Jose Ricardo Quaglio from comment #25)
Katrin Fischer,
We use version 18.11.03.000 and have a homologation server with version 19.05.04.000.
We are doing this to work around the problem.
This year the government did not apply "summer time".
I noticed that in version 19.05.04 this bug was adjusted, but I think it was not thought in case the government did not implement this time.
Tks,
a very late update, but this seems to be a problem with ubuntu-bionic perhaps try upgrading to a newer ubuntu version -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=32232 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org