There is a lot of thing that will end up confusing with our current date/time handling. We should be sticking to HTML5 input types to not confuse developers about what a drupal input type will give them.
The example I'll be refereeing to is the node add form.
When datetime module is not enabled we have: <input type="text"> and validation functions, all good.
When datetime is enabled:
array('#type' => 'datetime') will give you <input type="date"><input type="time"> and it will adjust for TZ. So that one is fine as 2 separated fields.
If I follow the doc to have a datetime-local element:
array('#type' => 'datetime-local', '#date_date_element' => 'datetime-local', '#date_time_element' => 'none') will give <input type="datetime-local"> as expected and it'll be adjusted for TZ.
So essentially Drupal datetime behaves like HTML datetime-local input. It still is pretty convoluted to make a HTML5 datetime-local input from Drupal datetime FAPI type.
There is also in system_element_info() this that I'm really not sure belongs:
$types['date'] = array(
'#input' => TRUE,
'#theme' => 'date',
'#theme_wrappers' => array('form_element'),
);
array('#type' => 'date') => <input type="date">
array('#type' => 'time') => <input type="time">
array('#type' => 'datetime') => <input type="datetime"> with TZ information (either Z or an offset like +02:00). If no TZ information the value is not valid.
array('#type' => 'datetime-local') => <input type="datetime-local"> without any TZ information (we suppose datetime TZ is user TZ).
Date + time should only be one field, no need for a date field and a separated time field.
#675348: META: Support HTML5 form input elements
#1496652: Add new HTML5 FAPI Element : datetime-local
#1972660: Add tests for the new HTML5 date elements 'date', 'datetime', 'datetime-local' and 'time'
#1835016: Polyfill date input type
Comments
Comment #1
longwaveThe system_element_info entry is a remnant of D7 (and dates to at least Drupal 4.7), but I don't think it even works properly any more in D8, and should probably be removed. See https://api.drupal.org/api/drupal/developer!topics!forms_api_reference.h... for how it used to work.
Comment #2
tim.plunkettComment #2.0
nod_Got datetime and datetime-local wrong :p
Comment #3
nod_Got a bit confused since I read the spec a while ago, updated the summary to be more accurate.
Changes boils down to HTML
datetimeinput must have TZ value with it. HTMLdatetime-localmust not have TZ value.Since we don't use either of those HTML types there is no "problem" but it still means that the drupal
datetimetype is essentially a HTMLdatetime-localinput.Comment #3.0
nod_reconfused
Comment #4
tim.plunkettI was just going to ask "is this truly major", and then I saw that I was the one who promited it...
@nod_, is this truly major? :)
Comment #5
nod_If you're trying to use the FAPI date things from code, yes it is.
I have a project with some pretty advanced date stuff in the works. Gave up trying to use D8 when I saw this API, yeah not a lot of willpower but I'm not the only one who'll be in that case.
Compared to the rest of our HTML5 form things, It's the only one that doesn't make sense when you look at it and compare what you should get as form elements.
Comment #6
tim.plunkettThen I retract my previous demotion :)
Comment #7
sunThe Expected chapter makes sense to me.
I only wonder whether we perhaps want to add a
#local => TRUEproperty to #type 'datetime', instead of having two separate #types?Comment #8
jhedstromProbably too late for 8.0.x since this would require some API changes (unless we could make it BC?).
Comment #9
mpdonadioI think at this point, with RC1 looming, we need to postpone this to 8.1.x.
Comment #10
catchNot looking at the priority, but this definitely falls into 'task' category for me - no functional bug.
Comment #12
jhedstromUn-postponing, although I'm not sure if this can be achieved without API changes...
Comment #27
smustgrave commentedWonder if still relevant and what's left?