Datepicker can't display different date formats in the input and in the modal title

[david-ru]

I'm trying to use format 'LL' for the input and a simpler one for the datepicker header ('DD MMMM YYYY'). Sadly, the component expects something different and gets crazy.

You can find an example of this here: https://github.com/david-ru/ionic4-datepicker-test.git

Regards.

[digvijayLogistic]

In this case you can use different datePickerObject for both. For example, use can send date in string as 'DD MMMM YYYY' format, then you can set dateFormat as 'DD MMMM YYYY' and you can set a date in string as 'LL' format then you can set dateFormat as 'LL' in this dateObject.

const firstDateObject : { ... dateFormat: 'DD MMMM YYYY', ... }

const secondDatePickerObj : { ... dateFormat: 'LL'', ... }

[david-ru]

But I only need one datepicker with a different format in each place (input and modal window title) and now it seems that both are binded to each other.

It'd be great to be able to do something like this:

<ion-input readonly [(ngModel)]="datePickerDate" 
       [liIonic4Datepicker]="datePickerObj" (ionChange)="onCalendarChange($event)">
</ion-input>

public datePickerObj;
public datePickerDate;
...
this.datePickerDate = moment(currentDate).format('LL');
...
this.datePickerObj: any = {
      inputDate: currentDate,
      ...
      dateFormat: 'DD MMMM YYYY',
      ...
}

[chintan13]

actually take different datePickerObj for both your inputs in this case, that way it will be solved automatically.

Technically it will always have only one date picker, so taking two different datePickerObj will not harm in any way.

Problem here is, datePickerObj can handle only one formate at a time and there is no way to differentiate in logic for it. In terms of use case also we should not implement in that way.

[david-ru]

I only have one input, so I'm afraid I still can't see how to "link" variable datePickerDate to different datePickerObj. Anyway, since the component can't handle different formats for the datePickerDate and the datePickerObj, there is no point in extending this further. Thanks for you time and effort.