Date properties

I'm currently looking into the new implementation of date properties.

I'm asking here before making any further changes so that we don't end
up changing this several times.

I have the following observations:
Previously a date property that didn't have a 'format' specified in the
date field() call in the template would render the date with time
included (unless a 'format' was explicitly specified). So even when you
entered 'YYYY-MM-DD' it would then be rendered as 'YYYY-MM-DD.hh:mm:ss'.
The new default is to use a html <input> element with type="date" not
type="datetime-local". This breaks many of my current templates because
it changes the default (the time is gone).

We also take the 'format' argument as a hint of using date vs.
datetime-local -- but we render it with a completely different format
chosen by the browser. So I can never force international format
currently, that's bad. The format should not be overloaded with new
magic.

I'm also not very happy with the addition of the new 'field_time'
method. There probably should be a 'field_date' method instead and the
default of the field method should be type="datetime-local". But see
next paragraph.

But maybe we should make the intended time format (if we need only the
date or date + time) part of the attributes of the 'Date' property
itself. So similar to a Link property where we have additional
parameters like "do_journal" or "rev_multilink" we could add a "type"
parameter to the Date property. This can then be used by the field()
call in the templates for selecting the proper html5 <input> type. I
would not tie this to the html5 input-type, though, rather use 'date'
vs. 'datetime' similar to python's datetime implementation (which has
'date' and 'datetime' objects). I think the default should be 'datetime'
because that is compatible with the current behavior.

That way the display of that property doesn't need to be hard-coded in
every template.

This can then be used to select the proper html5 input type. So if in
the future html grows something that is more usable than the current
implementation we can change the default rendering. We also can compute
the default format of the html date property when using the old calendar
widget.

I think we need options to force the old html (string) input types (for
both Date and Number properties). I think for Date properties the
default for now should be the *old* behavior (because I think the html5
date input type isn't ready for prime time). For consistency we could
make the default for Numbers also the old format or have a different
default.

Note that I've implied several times that the new html input type 'date'
(and datetime-local) isn't ready for prime time. This is my opinion
because it is tied to the language setting in the browser. Some browsers
even ignore the operating system settings for date/time (or use the
operating system setting only when specially configured). The current
implementation cannot force the international date format server-side.

I'm in a german-speaking country but I'm using a en_US.UTF-8 locale
(also in the browser). I've never seen english dates on websites wich
indicates that nobody is using the new date / datetime-local input types
on the web. Which seems to confirm my assessment above.

Let me know what you think!

Kind regards
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]