Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a datetimepicker instead of just a datepicker #83

Open
mueslo opened this issue Mar 31, 2017 · 9 comments
Open

Provide a datetimepicker instead of just a datepicker #83

mueslo opened this issue Mar 31, 2017 · 9 comments
Labels
feature 🔨 web/ui Things relating to Flask routes and Jinja templates

Comments

@mueslo
Copy link
Contributor

mueslo commented Mar 31, 2017

In some cases it is necessary to specify a datetime, not just a date.

@lukasjuhrich
Copy link
Collaborator

@mueslo Could you elaborate on some examples to show how relevant this is?

@ibot3
Copy link
Member

ibot3 commented Jun 2, 2019

It is required for some tasks that need to be executed on a specific time of a day. For example moving a user.

@lukasjuhrich
Copy link
Collaborator

The old bootstrap-datetimepicker has been forked into what seems to be a more actively maintained library which actively works on BS5 support: Tempus Dominus.
The current v5 supports BS4 and I will evaluate how well it works with BS5.

The project is undergoing a few structural changes (dropping the jQuery + even bootstrap dependency), but it's not clear when v6 will arrive. Judging by the blog article the developer seems to have the right priorities and is actually interested in building something stable + maintainable.

Pragmatically speaking, we don't even care about a nice UI, having the functionality is the main goal.

@lukasjuhrich lukasjuhrich changed the title Use bootstrap-datetimepicker instead of datepicker Provide a datetimepicker instead of just a datepicker Jul 31, 2021
@lukasjuhrich lukasjuhrich added feature 🔨 web/ui Things relating to Flask routes and Jinja templates and removed enhancement labels Jul 31, 2021
@lukasjuhrich
Copy link
Collaborator

Judging by Eonasdan/tempus-dominus#2326 and the state of the v6-alpha1-branch in the repo, it will be a while until this is stable. For #488 it might be better to just provide an optional time field.

@lukasjuhrich
Copy link
Collaborator

There's been an update in a blog post yesterday.

No time line, but sounds like it could be released in the next few months or perhaps even weeks.

@lukasjuhrich
Copy link
Collaborator

v6 is in beta 5 and judging by the examples it seems pretty usable.

We can even utilize the format/parse hooks to enforce an ISO-8601 text representation instead of the default MM/DD/YYYY HH:SS weirdness.

@lukasjuhrich
Copy link
Collaborator

lukasjuhrich commented May 25, 2022

Sneak preview: implicit UTC conversion! :-)
image

lukasjuhrich added a commit that referenced this issue May 25, 2022
lukasjuhrich added a commit that referenced this issue May 25, 2022
We need this for some reason to import the tempus-dominus module.

`classic` is considered legacy, anyway:

> This used to be TypeScript’s default resolution strategy. Nowadays,
> this strategy is mainly present for backward compatibility.

src: https://www.typescriptlang.org/docs/handbook/module-resolution.html#classic

Refs #83
@lukasjuhrich
Copy link
Collaborator

The current POC html skeleton is:

<form>
  <div
    class='input-group'
    data-td-target-input='nearest'
    data-td-target-toggle='nearest'
    data-role="datetimepicker"
  >
    <input
      class='form-control'
      aria-label="some date time"
      id="datetimepicker1"
      data-td-target='#datetimepicker1'
    />
    <button
      class="btn btn-outline-secondary"
      type="button"
      data-td-toggle="datetimepicker"
    >
      <span class='fa-solid fa-calendar'></span>
    </button>
  </div>
  </form>

lukasjuhrich added a commit to agdsn/wtforms-widgets that referenced this issue May 27, 2022
lukasjuhrich added a commit to agdsn/wtforms-widgets that referenced this issue May 27, 2022
This was double quoting things, ie kept things a little _too_ safe.

Refs agdsn/pycroft#83.
lukasjuhrich added a commit to agdsn/wtforms-widgets that referenced this issue May 27, 2022
lukasjuhrich added a commit that referenced this issue May 27, 2022
lukasjuhrich added a commit to agdsn/wtforms-widgets that referenced this issue May 27, 2022
Unfortunately we have to make this hard-coded distinction, because we
can only pass `render_kw` from the outside, and it's not quite clear
on which HTML element they need to end up.

Refs agdsn/pycroft#83
lukasjuhrich added a commit that referenced this issue May 27, 2022
lukasjuhrich added a commit that referenced this issue May 27, 2022
lukasjuhrich added a commit to agdsn/wtforms-widgets that referenced this issue May 27, 2022
lukasjuhrich added a commit that referenced this issue Mar 28, 2023
lukasjuhrich added a commit that referenced this issue Mar 28, 2023
We need this for some reason to import the tempus-dominus module.

`classic` is considered legacy, anyway:

> This used to be TypeScript’s default resolution strategy. Nowadays,
> this strategy is mainly present for backward compatibility.

src: https://www.typescriptlang.org/docs/handbook/module-resolution.html#classic

Refs #83
lukasjuhrich added a commit that referenced this issue Mar 28, 2023
@lukasjuhrich
Copy link
Collaborator

lukasjuhrich commented May 11, 2024

FWIW, the tempus dominus picker was really, really underwhelming in terms of basic UX. It did not seem to behave properly on tab-out, didn't always close when pressing on some other part of the area, etc.
This lead me to mistrust the developer of the repo a lot, given that he spent quite a bit of time with development, hence the tempus-dominus branch is more or less stale.

Googling around, flatpickr seems like a good alternative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature 🔨 web/ui Things relating to Flask routes and Jinja templates
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants