Your documentation examples should use a time of 13:00 or later to illustrate 12- versus 24-hour handling

[matthewadams]

The current documentation uses the time 11:45, which doesn't change based on locale. However, if you used, say, 14:34, the examples would be more illustrative when used across locales that default to 12- versus 24-hour time renderings.

[justin-schroeder]

In the code example? Currently I believe it is uses your browser’s time, but I’d be happy to accept an PR to change this

[matthewadams]

I didn't notice that you are using the viewer's current time, which happened to be 11:45 AM my time. Checked again & it's now 4:56 PM my time. I still think the example should always use a fixed time after 13:00 for illustrative purposes. I will not issue a PR at this time.

[jeltehomminga]

I am struggling to understand adding offset example

It says there is no offset, then it says +0100, and then after applying the offset the time stays the same at 9:30

can it have a bit more explanation or an extra example?

[hrynevychroman]

@justin-schroeder hello 👋

Main issue here is that is confusing to see 09:30 inside d variable, and after applyOffset we receive 09:30 too, this is because UTC format, so I think that add console.log for const d is more then enough to see difference, or maybe something else to add for this?

First we have 07:30 UTC, and after applyOffset with +0200, we receive 09:30 UTC

This question about second part of your comment https://github.com/formkit/tempo/pull/20#issuecomment-1961599415:

2. A few hard-coded times in the example.

[justin-schroeder]

I think that’s fair enough, lets change date(d) then to console.log(d) so people don’t assume any side effects.

[justin-schroeder]

I am struggling to understand adding offset example

It says there is no offset, then it says +0100, and then after applying the offset the time stays the same at 9:30

can it have a bit more explanation or an extra example?

@jeltehomminga the offset is essentially taking a time in your browser’s locale, and converting it to the same relative time (not absolute time) in the target location. This allows you to easily use normal Date objects on your UI (which is much easier than normalizing everything to some remote tz) and then adjust it back to the target TZ at the end.

To use the car rental example, if someone wants to rent a car at 9:30am in lisbon, but their browser is in tokyo, how can we do that? This example is intended to demonstrate that you can create an interface (datepicker or otherwise) that allows the user to select their pickup time using local Date objects (9:30am tokyo time) and then the offset application converts that to 9:30am in Lisbon.

Hopefully that makes sense!

[jeltehomminga]

Thanks for the great reply's. everything is clear now 👌🏼 The console log makes it much clearer for me indeed