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.

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.

(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.

A question: in this format a leading zero (as 01.04.2014) is forbidden
or allowed?

Switch to Needs Signoff, for your consideration

Setting back to paxed :)

Comment on attachment 27069 [details] [review]
Bug 12072 - New dateformat dd.mm.yyyy

Obsoleted, paxed version is better

Signed, again :)

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?

Marked as Failed QA.

(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.

(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.

(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.

This needs others QA points of view.

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.

We need this feature for Switzerland and it would be great to have it soon. Is anybody working on it at the moment?

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)?

(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.

I will try to move this forward by splitting it up to several steps / patches based on paxed's work.

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

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).

Still blocked by Bug 13813.

Note for development:
See also:
tools/exceptionHolidays.pl
tools/holidays.pl
tools/newHolidays.pl

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.

Depends on 13 bugs left to sign off as of today (see list in Bug 14870).

Addition to test plan: Run DateUtils.t

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.

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>

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>

Enhancement pushed to master.

Well done, Marc!