DateTime, Date and Time inputs

[MartinMystikJonas]

Features

• DateTimeInput, DateInput and TimeInput
• can be configured to return value as \DateTime. \DateTimeImmutable object or any offspring (like \Nette\DateTime or \Carbon\DateTime) ->setValueType(\Nette\DateTime::class)
• can be configure to return value as any object by setting callback that would transform DateTimeImmutable to required type (for example \Brick\DateTime\LocalDate ->setValueType([\Brick\DateTime\LocalDate::class, 'fromNativeDateTime']))
• set value by date/time object, string or timestamp
• ability to add custom html classes $control->setHtmlAttribute('class', 'custom-class');
• support both native date/datetime-local html inputs and text input with custom format new DateTimeInput("Date") // type="datetime-local" new DateTimeInput("Date", 'd.m.Y H:i') // type="text"
• in text input variant accept multiple formats (when parsing by one format fails go for next, final fall back to common formats) ->setFormats(['d.m.Y H:i', 'Y-m-d H:i']);
• pass parameters (like formats, min/max, custom settings) to data attributes of control (so it can be used to configure JS date picker) <input type="text" data-format="d.m.Y H:i" data-settings="{...json...}"
• allow use by adding extensionMethod to form container but also manual use by calling constructor and use addComponent
• not locked on particular frontend framework (like Bootstrap)
• support MIN, MAX and RANGE rules

• handle different input/server timezone ->setInputTimezone(new DateTimeZone('America/New_York'))

I prepared first draft of DateTime inputs as discussed in #7

Please check it and let me know if you like my general approach. If it would be ok I will add tests and documentation.

[f3l1x]

I think general approach is good. Maybe Parser can be interface, wdyt?

[MartinMystikJonas]

I am not sure there would ever be need for different implementations because this parser is configurable for any format. I made it to separate class so it can be eventually reused in other date/time inputs implementations. For example it could be eventually used by date/time inputs in contributte/forms-bootstrap instead of writing custom parser there.

[MartinMystikJonas]

Main decision I was not sure about was how to differentiate between creating native html date/datetime-local inputs or just normal text inputs allowing custom formats parsed server-side. I decided it would create native html/date/local-datetime if format was ommited and normal text inout if format(s) are specified. Do oyu think it is ok?

[f3l1x]

Ad parser) Agreed.

Ad native inputs) Agreed. I think it's OK.

[MartinMystikJonas]

One more thing. I saw that nextras DateTimeInput supports callback parsers for non-standard formats. Do you think we should support it too? It would not be too much complication. Parser would simply accept formats both as string or callback.

[MartinMystikJonas]

I added one more feature I was missing in one of our prtojects. Ability to specify input time zone (zime zone in which user enters values) and automatically convert DateTime objects passed to set Value or validation rules to this timezone.

Also we can then either convert value to default timezone or return in with correct timezopne set. Which would you think is better? Existing datetime inputs does not handle this.

[MartinMystikJonas]

Now it is fully tested and documented. It should be finished and ready for merge.

Someone please check docs if it is understandable a and check for typos (I have problem with typos escecially when I write in english) :-)

[dakur]

@MartinMystikJonas There is DaetTime instead of DateTime in FQNs in the docs everywhere. Sorry, I can't update it now.

And thank you for your effort!

[MartinMystikJonas]

I will fix it.

[MartinMystikJonas]

Typo with DaetTime fixed