On issue2550858, I proposed replacing a text input and calendar popup for
editing date/time fields with a native input of type date or datetime-local.

This doesn't handle every use case, but I think it handles the majority of
them and addresses all existing issues with the calendar popup.

As part of this change, the field method for DateHTMLProperty class 
changes popcal=True to popcal=False by default. It adds a new:

  field_time()

method for editing date and hours/minutes. Editing seconds only works
if the seconds value is not 0. If you need to add seconds, use a text
input (python:context.datefield.field(type="text", popcal=True)) to
allow editing for the full date format and enable popcal. (See below
for a double clicking action that helps this case.)

The value returned by a datetime-local is set to an RFC3339 format date_time.
The hyperdb Date class accepts input in the form YYYY-mm-DD.HH:MM:SS, but rfc3339
uses 'T' in place of '.'. So hyperdb Date will parse rfc3339 as well.

The field() and field_time() methods force the proper format when date or
datetime-local type is used. Trying to specify a format will result in an
exception.

I also created a javascript file on Thomas's suggestion we support copy/paste.
Including this file (see msg8268) allows copying of date/datetime-local by
double clicking on the input. This changes it to a text input that allows
copying or pasting. Note that this can also allow raw editing of the date/time
for editing/adding seconds. One thing to note is that the value shown is in
RFC3339 format not roundup full date format.

Using the native date/time should be an improvement for tablet users as well.
Note that double-click may not work on touch devices.

This change hides issues with backend the date interval calculations from the
front end, but we still need to handle the backend issues on another ticket.

Anybody want to try the patches?

See also: issue2551260, issue2550935, issue2550527, issue2551124

Hmm, I wonder if I should make field generate a datetime-local input
and have a new field_date use a date input when the user just wants
to edit a date without time.

I use field(format="%Y-%m-%d") in my trackers, so it acts like a date input.
Do any of you use the field method for input of full date and time?

* John Rouillard <issues@roundup-tracker.org> [20250115 03:06]:
> I use field(format="%Y-%m-%d") in my trackers, so it acts like a date input.
> Do any of you use the field method for input of full date and time?

Just the date should be fine here and improve the situation for
almost everyone. I've noticed our users use the time in very few
situations to indicate a hard deadline for finishing something
(e.g. this must be submitted before 14:00), but losing this isn't a
big deal.

Of course the indicators of "how much time until the deadline"
should be changed to days instead of hours as well and it shouldn't
be affected by daylight saving time (which currently sometimes
changes a time of midnight to an hour before midnight on the
previous day). I haven't checked if the patches already take care of
this.

I have been working through the changes and docs.

The biggest hangup is handling format strings for the dates.
For example:  in German, "%d-%m-%Y" is common, for the US: "%m-%d-%Y"
is common.

After this change, when using the native date input, the format must be
"%Y-%m-%d" so that the native date input can parse/display it. Currently
the code throws an exception if format is set and does not exactly match
the required format.

Similar rules apply for datetime-local inputs.

I am considering just ignoring format if the input type is a
native date/datetime-local.

Alternatvely, ignore the date if it looks compatible. For example: "%m,%d|%Y"
is compatible with a date input. I can do this with )use set to get rid of ordering
issues):

  set(re.findall('%([A-z])', format)) == set("Y", "m", "d")

to consider the format compatible with 'date' and

   set(r.findall(...)) in [set(['Y', 'm', 'd', "H", "M"]),
                           set(['Y', 'm', 'd', "H", "M", "S"])]

to consider it compatible with datetime-local. A year/month format like: "%m-%Y" would
not be compatible and would throw an exception. (Yes weird formats like:
"%Y: %m %m-%d will be incorrectly accepted but ... they deserve it 8-).)

I don't like spending cpu cycles doing the compatibility test, but...

Thoughts?