For some more rare cases this is already done, but a lot of dates are still in 'database format'. Example: 2012-11-14 20:50:00. This bug is for listing the problematic dates. Check in notice: <<old_issues.date_due>> <<old_issues.branchcode>> <<old_issues.returndate>> <<old_issues.issuedate>> Check out notice: <<issue_date>> Note: <<issue_date_due>> doesn't work at all
Note: <<issue_date_due>> doesn't work at all < that's wrong, it was a typo in my template.:) Check in notice: <<old_issues.date_due>> <<old_issues.branchcode>> <<old_issues.returndate>> <<old_issues.issuedate>> Check out notice: <<issue_date>> <<issue_date_due>>
(In reply to comment #0) > For some more rare cases this is already done, but a lot of dates are still > in 'database format'. Example: 2012-11-14 20:50:00. This bug is for listing > the problematic dates. hmmm, we have just bumped into this issue too... i may be attempting a fix for this - if no one else has a fix already?
Created attachment 17524 [details] [review] Bug 9084 - Dates in notices should be formatted according to dateformat system preference
Created attachment 17525 [details] [review] Bug 9084 - Dates in notices should be formatted according to dateformat system preference
Created attachment 17526 [details] [review] Bug 9084 - Dates in notices should be formatted according to dateformat system preference
Created attachment 17827 [details] [review] Bug 9084 - Dates in notices should be formatted according to dateformat system preference to test… - apply patch - choose a patron to checkout item - in 'Patron messaging preferences' section, of patrons 'details' page - tick 'email' box for 'Item checkout' ---------------------------------------- Patron messaging preferences Days in advance Email Item checkout - x <==== Hold filled - - Item due - - Item check-in - - ---------------------------------------- - cut/paste below notice, for CHECKOUT, in 'Home › Tools › Notices & Slips › Modify notice' bib: <<biblio.title>> due: <<issues.date_due>> issue: <<issues.issuedate>> return: <<issues.returndate>> - delete issues and message_queue tables, before test mysql> truncate issues; mysql> truncate message_queue; - issue a test item to patron - check message_queue table for notice, with correctly formatted dates, with stripped time mysql> select content from message_queue\G content: bib: TESTAMENTS OF LOVE due: 20/05/2013 issue: 30/04/2013 return: 30/04/2013 1 row in set (0.00 sec)
Created attachment 17828 [details] [review] Bug 9084 - Dates in notices should be formatted according to dateformat system preference to test… - apply patch - choose a patron to checkout item - in 'Patron messaging preferences' section, of patrons 'details' page - tick 'email' box for 'Item checkout' ---------------------------------------- Patron messaging preferences Days in advance Email Item checkout - x <==== Hold filled - - Item due - - Item check-in - - ---------------------------------------- - cut/paste below notice, for CHECKOUT, in 'Home › Tools › Notices & Slips › Modify notice' bib: <<biblio.title>> due: <<issues.date_due>> issue: <<issues.issuedate>> return: <<issues.returndate>> - delete issues and message_queue tables, before test mysql> truncate issues; mysql> truncate message_queue; - issue a test item to patron - check message_queue table for notice, with correctly formatted dates, with stripped time mysql> select content from message_queue\G content: bib: TESTAMENTS OF LOVE due: 20/05/2013 issue: 30/04/2013 return: 30/04/2013 1 row in set (0.00 sec)
Perhaps it would be better (quicker) if you made a hash instead of array, and use if $h{$field} instead of grep?
Patch applied cleanly, go forth and signoff
I'm happy to see that someone else has already started work on this one. However, I have a few reservations about this patch at the moment. 1) The list of tables.fields for which to format dates: This list isn't comprehensive (it should probably include all date columns). Also, being hard-coded, it makes for a bit of a maintenance nightmare, I think. The overdue_notices.pl and advanced-notices.pl scripts use this regex "/^date|date$/" to choose columns for which to format dates when using items.content. I think that this would make sense here too. Of course, "items.onloan" wouldn't be included in this, so we might need to use a hard-coded list, or regex + a shorter hard-coded list. 2) I don't know if we want to strip the time from all of these fields. I imagine there might be fields, like duedate, where we might want to include the time. We might not. I'm not 100% on this one. -- In any case, if the list were expanded, I would be happy to sign off.
I hope it's appropriate that I mark this RESOLVED - DUPLICATE, but bug 11244 identifies the same problem and offers a more robust solution. *** This bug has been marked as a duplicate of bug 11244 ***