Looks like gmail isn't sending this via smtp, only TLS smtp.

Anyway my response:

Hi Ralf:

On Mon, Jan 27, 2025 at 3:57 AM Ralf Schlatterbeck
<issues@roundup-tracker.org> wrote:
> On Fri, Jan 24, 2025 at 02:08:39PM +0000, Thomas Arendsen Hein wrote:
> > * John Rouillard <issues@roundup-tracker.org> [20250124 14:25]:
> > > I am also open to unclosing the date picker issues (which may have to happen anyway)
> > > and reverting this patch.
> >
> > The native date picker is so much nicer than the old JS one that I'd
> > be willing to endure any usability issues with the date format :)
> Yes, I think so, too
>
> Maybe we can find a solution where the new time picker is used but
> custom javascript is only inserted into the template when the time
> format is being forced.

That would be custom javascript to overlay a custom formatted date display
correct?

> This at least reduces the problem of maintaining custom javascript for
> most people.

The existing doubleclick handler that turns the date input into a text
input (with YYYY-mm-ddTHH:MM[:SS] doesn't have much JS. Also it is
needed to add seconds. If the time has 0 seconds, the date input won't
display them for editing. All in all it is a very simple bit of JS
that shouldn't need maintenance.

I assume you want to try creating a JS module to display a tracker
localized date format, that's much more complex to get right. Browser
date inputs look different, have different sizes
(which might not be controlled by the CSS width property).

> Since I would be one of the users at least a change would be detected :-)

True. We don't have a good frontend testing framework. The grad
students who produced the new classhelper also developed a front
end test with selenium. However it developed timing issues in some
test cases and wouldn't run to completion reliably. Of course it
failed during the final class demo despite working fine in all
the prior demos 8-(.

> I try to make some time for looking into this more closely...

If you want to discuss:

  > javascript to overlay the edit display with a static date display

a new issue linked here would be good. The existing doubleclick
handler might be useful to look at as a model.

(added on resubmit) The doubleclick handler applies one handler to
the page saving memory. So adding a new doubleclick handler for your
date overlay span should work fine. However to create the overlay,
you would have to run when the DOM is complete and replace/overlay
all the date/datetime-local elements on the page with the formatted
display.

Any newly added elements (e.g. due to javascript) IIUC would
have to be processed as part of a mutation observer. I have no clue
how that works.