Bug 12072

Summary: New dateformat dd.mm.yyyy
Product: Koha Reporter: paxed <pasi.kallinen>
Component: I18N/L10NAssignee: Marc Véron <veron>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: bgkriegel, f.demians, jonathan.druart, josef.moravec, katrin.fischer, mirko, pasi.kallinen, tomascohen, veron
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13813
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14060
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14794
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14936
Change sponsored?: --- Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 14870, 15166    
Bug Blocks:    
Attachments: Bug 12072 - New dateformat dd.mm.yyyy
Bug 12072 - New dateformat dd.mm.yyyy
Add dateformat dd.mm.yyyy
Add date format dd.mm.yyyy, known internally as dmydot.
[SIGNED-OFF] Add date format dd.mm.yyyy, known internally as dmydot.
Bug 12072 - Follow up to fix koha-qa errors
Add dateformat dd.mm.yyyy
[SIGNED-OFF] Bug 12072: Add date format dd.mm.yyyy.
Bug 12072 - Step 1: Add system preference for New dateformat dd.mm.yyyy
[SIGNED-OFF] Bug 12072 - Step 1: Add system preference for New dateformat dd.mm.yyyy
Bug 12072 - Step 1: Add system preference for New dateformat dd.mm.yyyy
Bug 12072 - Add system preference for New dateformat dd.mm.yyyy (dmydot)
Bug 12072 - Add system preference for New dateformat dd.mm.yyyy (dmydot)
Bug 12072 - Add system preference for New dateformat dd.mm.yyyy (dmydot)
Bug 12072 - Add system preference for New dateformat dd.mm.yyyy (dmydot)
Bug 12072: Make datepicker and templates to be aware of dmydot format
Bug 12072: Make datepicker and templates to be aware of dmydot format
Bug 12072: Make datepicker and templates to be aware of dmydot format
[PASSED QA] Bug 12072 - Add system preference for New dateformat dd.mm.yyyy (dmydot)
[PASSED QA] Bug 12072: Make datepicker and templates to be aware of dmydot format

Description paxed 2014-04-11 10:32:10 UTC
We need a dateformat like "dd.mm.yyyy" but just adding that into C4/Dates.pm, Koha/DateUtils.pm and i18n_l10n.pref -files isn't enough, because the allowed date formats are hard-coded in multiple template like this:

[% IF ( dateformat == "us" ) %]mm/dd/yy[% ELSIF ( dateformat == "metric" ) %]dd/mm/yy[% ELSE %]yy-mm-dd[% END %]

The dateformat style should be passed to the templates instead.
Comment 1 Katrin Fischer 2014-04-11 11:03:13 UTC
The proposed new date format would be useful for us as well. Date handling has been improved a lot using TT plugins and includes in the past, but I guess more clean up would be good.
Comment 2 Owen Leonard 2014-04-11 13:34:53 UTC
Template output of date formats is handled by three include files: one for the staff client and one each for the prog and bootstrap themes. This doesn't seem like an unreasonable number of templates to modify.

The only exception that I can find is circ/offline.tt. That template should be updated to use the include.
Comment 3 Owen Leonard 2014-04-11 13:52:39 UTC
(In reply to Owen Leonard from comment #2)
> The only exception that I can find is circ/offline.tt. That template should
> be updated to use the include.

Correction: This template needs different date format handling because it's setting a JavaScript variable.
Comment 4 Bernardo Gonzalez Kriegel 2014-04-14 04:29:18 UTC Comment hidden (obsolete)
Comment 5 Bernardo Gonzalez Kriegel 2014-04-14 04:32:42 UTC
A question: in this format a leading zero (as 01.04.2014) is forbidden
or allowed?

Switch to Needs Signoff, for your consideration
Comment 6 Bernardo Gonzalez Kriegel 2014-04-14 04:36:06 UTC Comment hidden (obsolete)
Comment 7 paxed 2014-04-14 10:33:02 UTC Comment hidden (obsolete)
Comment 8 Bernardo Gonzalez Kriegel 2014-04-14 22:09:17 UTC
Setting back to paxed :)
Comment 9 Bernardo Gonzalez Kriegel 2014-04-14 22:10:04 UTC
Comment on attachment 27069 [details] [review]
Bug 12072 - New dateformat dd.mm.yyyy

Obsoleted, paxed version is better
Comment 10 Bernardo Gonzalez Kriegel 2014-04-14 22:18:22 UTC Comment hidden (obsolete)
Comment 11 Bernardo Gonzalez Kriegel 2014-04-14 22:19:19 UTC Comment hidden (obsolete)
Comment 12 Bernardo Gonzalez Kriegel 2014-04-14 22:20:27 UTC Comment hidden (obsolete)
Comment 13 paxed 2014-04-15 08:44:36 UTC Comment hidden (obsolete)
Comment 14 Bernardo Gonzalez Kriegel 2014-04-15 13:48:52 UTC Comment hidden (obsolete)
Comment 15 Bernardo Gonzalez Kriegel 2014-04-15 13:49:29 UTC
Signed, again :)
Comment 16 Jonathan Druart 2014-04-16 10:41:22 UTC
Comment on attachment 27130 [details] [review]
[SIGNED-OFF] Bug 12072: Add date format dd.mm.yyyy.

Review of attachment 27130 [details] [review]:
-----------------------------------------------------------------

::: C4/Dates.pm
@@ +40,4 @@
>  
>  sub _prefformat {
>      unless ( defined $prefformat ) {
> +        $prefformat = C4::Context->preference('dateformat') || 'us';

I disagree with setting a default value for this pref. It must exist in DB.

::: C4/Templates.pm
@@ +112,4 @@
>      $vars->{opacsmallimage} = C4::Context->preference('opacsmallimage');
>      $vars->{opaclayoutstylesheet} =
>          C4::Context->preference('opaclayoutstylesheet');
> +    $vars->{dateformatstyle} = C4::Dates->new()->formatstr();

1/ Prefer to use Koha::DateUtils instead of C4::Dates.
2/ C4::Dates is not used in C4::Templates.
3/ Prefer to sent variable to template in C4::Auth (common way to do).
4/ Very good initiative!

::: koha-tmpl/intranet-tmpl/prog/en/modules/circ/offline.tt
@@ +283,4 @@
>          return;
>      }
>      var date_due = new Date($('#duedatespec').datepicker('getDate'));
> +    date_due.setHours(23, 59);

Hum... why this change?
Comment 17 Jonathan Druart 2014-04-16 10:41:38 UTC
Marked as Failed QA.
Comment 18 paxed 2014-04-16 11:25:00 UTC
(In reply to Jonathan Druart from comment #16)
> Comment on attachment 27130 [details] [review] [review]
> [SIGNED-OFF] Bug 12072: Add date format dd.mm.yyyy.
> 
> Review of attachment 27130 [details] [review] [review]:
> -----------------------------------------------------------------
> 
> ::: C4/Dates.pm
> @@ +40,4 @@
> >  
> >  sub _prefformat {
> >      unless ( defined $prefformat ) {
> > +        $prefformat = C4::Context->preference('dateformat') || 'us';
> 
> I disagree with setting a default value for this pref. It must exist in DB.

How can it exist before Koha is installed? The installer uses templates, and
as dateformatstyle is passed on to templates... I guess part 2 below solves that problem then.

> 
> ::: C4/Templates.pm
> @@ +112,4 @@
> >      $vars->{opacsmallimage} = C4::Context->preference('opacsmallimage');
> >      $vars->{opaclayoutstylesheet} =
> >          C4::Context->preference('opaclayoutstylesheet');
> > +    $vars->{dateformatstyle} = C4::Dates->new()->formatstr();
> 
> 1/ Prefer to use Koha::DateUtils instead of C4::Dates.
> 2/ C4::Dates is not used in C4::Templates.
> 3/ Prefer to sent variable to template in C4::Auth (common way to do).
> 4/ Very good initiative!

1/ Because Koha::DateUtils doesn't do what is needed here - it knows nothing about the actual formatting string, just a user-friendly format name like "metric".
2/ True, that needs to be added.
3/ Didn't know about that.
4/ Just bare necessity.

> 
> ::: koha-tmpl/intranet-tmpl/prog/en/modules/circ/offline.tt
> @@ +283,4 @@
> >          return;
> >      }
> >      var date_due = new Date($('#duedatespec').datepicker('getDate'));
> > +    date_due.setHours(23, 59);
> 
> Hum... why this change?

Because offline UI showed the date AND the time in the datetimepicker... but the time was always hardcoded to 23:59. The other change in the offline UI was to remove the time display from the datepicker.
Comment 19 Jonathan Druart 2014-04-16 11:48:06 UTC
(In reply to paxed from comment #18)
> > 1/ Prefer to use Koha::DateUtils instead of C4::Dates.
> > 2/ C4::Dates is not used in C4::Templates.
> > 3/ Prefer to sent variable to template in C4::Auth (common way to do).
> > 4/ Very good initiative!
> 
> 1/ Because Koha::DateUtils doesn't do what is needed here - it knows nothing
> about the actual formatting string, just a user-friendly format name like

Is is not a good idea to continue to add code in C4::Dates.
Comment 20 paxed 2014-04-17 04:40:00 UTC
(In reply to Jonathan Druart from comment #19)
> (In reply to paxed from comment #18)
> > > 1/ Prefer to use Koha::DateUtils instead of C4::Dates.
> > > 2/ C4::Dates is not used in C4::Templates.
> > > 3/ Prefer to sent variable to template in C4::Auth (common way to do).
> > > 4/ Very good initiative!
> > 
> > 1/ Because Koha::DateUtils doesn't do what is needed here - it knows nothing
> > about the actual formatting string, just a user-friendly format name like
> 
> Is is not a good idea to continue to add code in C4::Dates.

Yes, someone should move the missing functionality from there to Koha::DateUtil then. That doesn't sound like it's relevant to this feature enhancement, though.
Comment 21 Jonathan Druart 2014-04-22 07:16:43 UTC
This needs others QA points of view.
Comment 22 Katrin Fischer 2014-04-28 16:02:10 UTC
After consulting with Galen and as we now have officially deprecated the use of C4::Dates, this will need a follow-up moving the code to Koha::DateUtils.
Comment 23 Marc Véron 2015-02-11 09:39:46 UTC
We need this feature for Switzerland and it would be great to have it soon. Is anybody working on it at the moment?
Comment 24 Mirko Tietgen 2015-02-18 14:48:08 UTC
I would like to see this resolved somehow, it's the standard date format for Germany too. Do I understand correctly that this is not going in before someone refactors stuff that is currently done in C4::Dates to be done in Koha::DateUtils (which is not really within the scope of this bug)?
Comment 25 Jonathan Druart 2015-02-18 15:21:07 UTC
(In reply to Mirko Tietgen from comment #24)
> I would like to see this resolved somehow, it's the standard date format for
> Germany too. Do I understand correctly that this is not going in before
> someone refactors stuff that is currently done in C4::Dates to be done in
> Koha::DateUtils (which is not really within the scope of this bug)?

The patch adds new enh in a deprecated module, so yes it's in the scope of this patch.
Comment 26 Marc Véron 2015-03-07 07:35:59 UTC
I will try to move this forward by splitting it up to several steps / patches based on paxed's work.
Comment 27 Marc Véron 2015-03-07 07:46:18 UTC Comment hidden (obsolete)
Comment 28 Marc Véron 2015-03-09 10:59:37 UTC
For the next steps we have the following problem:

- It is not allowed to touch C4::Dates (deprecated module, Comment #25)
- A new date format leads to error messages for example with C4::Dates->new(), which is used by about 50 files *).
- Koha::DateUtils is a temporary module for wrappers to hide the complexity of switch to DateTime. It contains some functions, but it is not really a replacement for the C4::Dates object.
- Replacing C4::Dates affects a lot of files and needs a lot of testing (side effects)

Plumbing 50+ files is far outside the scope of this bug. It is an architecural task. We should move the replacement of C4::Dates to a separate architectural / plumbing bug (that blocks this one and others as well).


----

*) Files using C4::Dates->new()
C4/Acquisition.pm
C4/Barcodes/annual.pm
C4/Barcodes/hbyymmincr.pm
C4/Calendar.pm
C4/Circulation.pm
C4/Items.pm
C4/Log.pm
C4/Members.pm
C4/Reserves.pm
C4/Utils/DataTables.pm
acqui/histsearch.pl
acqui/invoice.p
acqui/invoices.pl
acqui/orderreceive.pl
acqui/parcel.pl
acqui/parcels.pl
labels/label-item-search.pl
members/memberentry.pl
members/moremember.pl
members/readingrec.pl
misc/cronjobs/gather_print_notices.pl
misc/cronjobs/overdue_notices.pl
misc/cronjobs/serialsUpdate.pl
misc/cronjobs/staticfines.pl
misc/cronjobs/thirdparty/TalkingTech_itiva_outbound.pl
misc/maintenance/fix_accountlines_date.pl
opac/opac-memberentry.pl
opac/opac-showreviews.pl
opac/opac-user.pl
patroncards/members-search.pl
reports/dictionary.pl
reports/guided_reports.pl
serials/member-search.pl
serials/serials-edit.pl
serials/showpredictionpattern.pl
serials/subscription-renew.pl
t/Dates.t
t/Dates.t
t/db_dependent/Holds.t
t/db_dependent/Koha_template_plugin_KohaDates.t
t/db_dependent/Log.t
tools/exceptionHolidays.pl
tools/export.pl
tools/holidays.pl
tools/import_borrowers.pl
tools/newHolidays.pl
tools/scheduler.pl
Comment 29 Bernardo Gonzalez Kriegel 2015-03-10 11:51:18 UTC Comment hidden (obsolete)
Comment 30 Marc Véron 2015-04-26 07:08:58 UTC
Added Bug 14060 as related because of function validate_date in intranet-tmpl/prog/en/includes/calendar.inc (will need adjustments for new date format dd.mm.yyyy).
Comment 31 Marc Véron 2015-08-28 07:34:12 UTC
Still blocked by Bug 13813.
Comment 32 Marc Véron 2015-10-04 20:12:16 UTC
Note for development:
See also:
tools/exceptionHolidays.pl
tools/holidays.pl
tools/newHolidays.pl
Comment 33 Marc Véron 2015-10-10 11:36:30 UTC Comment hidden (obsolete)
Comment 34 Marc Véron 2015-10-10 12:42:32 UTC Comment hidden (obsolete)
Comment 35 Marc Véron 2015-10-10 12:52:37 UTC
For preliminary testing it is a good idea to have Bug 14985 applied.

For full testing we need all Bugs where Bug 14870 depends on.
Comment 36 Marc Véron 2015-10-25 19:45:02 UTC
Depends on 13 bugs left to sign off as of today (see list in Bug 14870).
Comment 37 Marc Véron 2015-11-05 08:18:21 UTC Comment hidden (obsolete)
Comment 38 Marc Véron 2015-11-05 08:22:02 UTC
Addition to test plan: Run DateUtils.t
Comment 39 Josef Moravec 2015-11-06 21:09:52 UTC Comment hidden (obsolete)
Comment 40 Marc Véron 2015-11-11 12:53:03 UTC Comment hidden (obsolete)
Comment 41 Marc Véron 2015-11-18 16:56:12 UTC Comment hidden (obsolete)
Comment 42 Marc Véron 2015-11-18 17:27:27 UTC Comment hidden (obsolete)
Comment 43 paxed 2015-11-19 07:45:45 UTC
I think all that repeated

if (dateformat == "us") blah
elseif (dateformat == "metric") blah
elseif (dateformat == ...

code in multiple places is fragile and errorprone, and therefore should be replaced with perl code that gets the date format string to the templating system.
Comment 44 Marc Véron 2015-11-19 09:32:09 UTC Comment hidden (obsolete)
Comment 45 Katrin Fischer 2015-11-19 15:16:28 UTC
Created attachment 45020 [details] [review]
[PASSED QA] Bug 12072 - Add system preference for New dateformat dd.mm.yyyy (dmydot)

Note: This feature depends on Bug 14870 'Delete C4/Dates from system'

System preferences:
To test:
- apply the patch
- run updatedatabase.pl
- go to Admin > Sysprefs > I18N, change dateformat to dd.mm.yyyy, save
- verify that the value was saved

Date handling:
- go through the staff client and verify that dates behave as expected.
- go through Opac and verify that dates behave as expected.

  The Bugs where Bug 14870 depends on contain test plans that can be
  used for the overall testing.

Note: Make sure that you reset the dateformat to the former value after
      testing.

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Works as expected

Amended to apply on top of Bug 15166 11.11.2015/mv

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 46 Katrin Fischer 2015-11-19 15:23:49 UTC
Created attachment 45022 [details] [review]
[PASSED QA] Bug 12072: Make datepicker and templates to be aware of dmydot format

This patch is to display corrextly the new dmydot date format e.g. after
using the datepicker or in messages for the user, in following files:

- koha-tmpl/intranet-tmpl/prog/en/includes/calendar.inc
- koha-tmpl/intranet-tmpl/prog/en/includes/date-format.inc
- koha-tmpl/intranet-tmpl/prog/en/includes/patron-search.inc
- koha-tmpl/intranet-tmpl/prog/en/modules/tools/holidays.tt
- koha-tmpl/opac-tmpl/bootstrap/en/includes/calendar.inc
- tools/holidays.pl

To test:
- Apply patch
- Make sure that you have syspref dateformat set to dmydot
- Use datepicker in OPAC (modify birth date), verify that after
  choosing a date, it is displayed correctly in the datepicker
- Use datepicker at several places in OPAC, verify that after choosing
  a date the date displays properly in datepicker and that the dater format
  is properly indicated (e.g. near birth date or near "Specify due date").
- Verify that datepicker works well with hoiday editing and that "From date:"
  displays properly

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 47 Tomás Cohen Arazi 2015-11-19 23:18:58 UTC
Enhancement pushed to master.

Well done, Marc!