EDIT

Implemented

please review, for the page used by the integration test, please see : http://int.e-taxonomy.eu/dataportal/integration/reference/cdm_dataportal/taxon/c246856f-c03e-4cb7-ac92-d9b2864084cd

Generally it looks fine.

Only the formatting maybe needs discussion. It differs from the default formatting of time periods in cdmlib. Is there a reason for doing this? Shouldn't we try to use a common formatting? Or is it configurable (whould be the best to allow configuring for all timeperiods at 1 place for the data portal.
The problem in the dataportals is that formatting might be locale dependent, especially for months but also for the format itself.

The current format is not nice for year periods, e.g. 2017-18 is currently formatted as 2017-00-00 to 2018-00-00. We should generally omit month and day if they are not given AND in case of months no day is given.
Also formatting without year is unclear 00-05-06 might be Jun 2006 or any 6th of May (but not urgent as such data usually does not exist). For sure "Jun" would be better then 00-06-00 but is a bit language dependent so needs further improvement.

So formatting for TimePeriod needs further discussion in general.

===

Minor issue: Testdata has "Mai to June" is mixture of German and English, I think we should use "May to June" instead.

Andreas Müller wrote:

Generally it looks fine.

Only the formatting maybe needs discussion. It differs from the default formatting of time periods in cdmlib. Is there a reason for doing this?

The cdmlib formatting is quite ugly in some cases:

a date with only a month (May) is shown in the taxeditor as #####-05-## which is also not no nice.

I suggest implementing a time period dto which handles the formatting consistently in the whole platform while respecting client localization preferences submitted via HTTP-headers.

Minor issue: Testdata has "Mai to June" is mixture of German and English, I think we should use "May to June" instead.

This is only freetext data, changing this would require ~15 minutes work and is not worth the effort.

I suggest to close this ticket now, agreed?

Andreas Kohlbecker wrote:

I suggest to close this ticket now, agreed?

What I really don't like in the current implementation is the trailing zero implementation for dates which have e.g. a year but no more specific date (month, day). It looks like 2017-00-00 to 2018-00-00 . Having only a year or a year and a month but no day is a very common use case but the formatting does not look nice. Can we still try to remove these trailing zeros (only for the case that a year exists)?

Andreas Müller wrote:

Andreas Kohlbecker wrote:

Can we still try to remove these trailing zeros (only for the case that a year exists)?

Ok, I will try that, but will copy this request to a new ticket ....

As there is the follow up ticket in 5.7 I move this back to 5.6 as the current implementation was done in 5.6