Better datetime picker

[jacobobryant]

Once again there's a native component I had no idea existed.

[mathushabai]

Hi, what's your preferred format for the datetime picker?

[jacobobryant]

I don't have any strong preferences. We just need to be able to populate the publish date attribute and have it be nicer to use than the current plain text field. The native component linked above looks alright to me. Or we could do separate components like Ghost does:

We'll need to account for timezone somehow--I see Ghost does this by just using UTC for the time field. That could be OK, or we could have an additional timezone field that gets auto-populated on the client side.

It might be worth taking a look at drop-in javascript components, maybe there's something that'd be better than the native component.

[CodeWithUmair]

Hello! @jacobobryant I'm interested in learning more about your problem, so please provide additional information.

[jacobobryant]

@CodeWithUmair what additional information would be helpful? Have you been able to run Platypub locally? If so you can go to the post edit page to see the current "Publish date" field.

[MTrost]

Hi @jacobobryant

Yesterday I forked platypub, changed the date picker from input type text to input type datetime-local and noticed that the native date picker sends a date time string without any timezone information.

Possible solutions:

1. Just assume UTC and provide a description to the input field, e.g. "Use UTC time zone"
2. Use a hidden input:
   1. providing the browser's time zone new Date().getTimezoneOffset(), or
   2. a user's time zone setting (as suggested in the linked article)
3. Use an input set by the user (can be a very simple number input with attributes step=1 and max=14 and min=-12 or a more elaborate select with cities and hours)

2.i needs code running client side. As I have not written any ClojureScript yet (and new to Clojure), I would need some assistance.

What do you prefer? I would probably go for 1. to close this issue and open a new one for 3.

[jacobobryant]

1 sounds good to me. In the Ghost screenshot above they just put a (UTC) in the time field.

I'm not sure if 2 or 3 would be best as a next step or if it'd be better to look for a drop-in js component that handles time zone (perhaps by defaulting to browser's time zone but allowing an override). In any case, we can close this issue after 1 is done and then wait a bit to see if it feels worthwhile to do something fancier--maybe UTC will be good enough.

[MTrost]

Thanks for the reply, I plan on working on this Friday afternoon (European time) or Saturday and will try it out with two input fields.

(and sorry for more or less asking the questions you already answered in the comment above: Somehow I only read the text above the pictures...)

[jacobobryant]

Sounds great! And no worries 🙂

[MTrost]

So over 2 months later I finally opened a PR for this 😄

UTC is appended to the label, e.g. "Published (UTC)" and not as part of the input field, which would have required more structural html changes.