Creating events doesn't respect user's 12 hour time locale

There is a small bug where the plugin does not respect the user’s 12-hour time locale when creating an event, and instead always shows 24-hour time locale. This makes entering events cumbersome and error-prone for US users who don’t use 24-hour time.

(It does render correctly after event is created, fortunately)

Otherwise looks like a great plugin, thank you :slight_smile:

Also, it would be nice if there was a setting to tune the limit of reminders that an event poster can place on an event. 5 is a lot :sweat_smile:

1 Like

Thanks for pointing this out! I have had the same experience when inserting date/time in a topic, which shares the same problem. I believe this is a known issue and there is an explanation for it. The input follows your device region, not the locale set in your discourse preferences. But the display does follow your locale discourse preferences (and also of any user looking at your post containing an event or date/time). Can you confirm this on your end?

It would certainly be less confusing and better UX if they were the same for the user creating the event or adding date/time to a post.

Here’s a demonstration. Note in screenshot below the 4:00pm selected time but 16:00 in the input. The reason this is happening to me is that I have my device region set to Germany (which uses 24 hour time), while my Discourse locale is US-WA (which users 12 hour time). The input seems to follow the device locale.

This appears as [date=2025-04-01 time=16:00:00 timezone="America/Los_Angeles"] in markdown which displays correctly to me as 4pm: 2025-04-01T23:00:00Z.

Changing my device region to United States brought these two in line, but is a cumbersome process requiring a restart.


With my region set to United States, when I insert date/time in a topic the input time is also in 12 hour time. The markdown is the same [date=2025-04-01 time=16:00:00 timezone="America/Los_Angeles"] and displays correctly as 4pm: 2025-04-01T23:00:00Z.

2 Likes

Thank you for the detailed reply (and from a fellow Washingtonian no less :))

So, this bug is actually regarding the “insert event” (official plugin), not the “insert date/time” (built-in). I completely relate to the confusion as when I first tried using the plugin, I also clicked the date/time instead of the event and was confused as to why it didn’t generate the event.

Since we both got confused about that, there might be opportunity to improve the UI:

  • In an ideal world, perhaps these could be merged into a single button, which prompts the user if they are trying to make an event or a time. (This would require a lot of code rework though)
  • More simply, if the event button was directly adjacent to the date/time button, instead of hidden under the more gear it would probably alert the user there are two different flows available. (Have not looked into if this is possible, but seems easier implementation-wise)

That said, to answer your queries:

  • :white_check_mark: When I use the insert date/time, it does indeed show 12-hour time for me
  • :cross_mark: It’s only when I use insert event that it requires 24-hour time

Regarding device region, I am not on iOS so I am not sure what this setting corresponds to on other operating systems. (I am on linux and verified my locale is returning all en_us or en_US.UTF-8… but maybe there is some other setting hidden). Can you confirm if you are seeing the same behavior on the ‘insert event’ page (not just ‘insert date/time’?) It doesn’t seem to be enabled for this forum, so you might have to spin up a test instance, though since it’s an official plugin should be easy to get a hold of.

3 Likes

Oh, interesting! So I went down the rabbit hole explaining how it works for inserting date/time, and the behavior is actually different. :facepalm: I just checked (being still in the United States region according to my device) and see that you are indeed right! The “Add event” popup does ask for the time in 24 hour time, even though inserting date/time insert is now in 12 hour time.

Insert date/time is a core feature while “Add event” is part of the calendar-and-event plugin. These are very separate features. So let’s focus here on the “Add event” popup which appears to have a UX bug, which you’ve perfectly documented in the first post of this topic.

Improving the UI in the composer menu is a totally different conversation. If you want to start a new topic about that, feel free.

2 Likes

It doesn’t make a lot of sense to have the two mechanisms different - but I guess that is another / separate UX issue!

This is absolutely needed!! It has been a problem for a long time (and perhaps justifies its own UX topic). I hide the Insert date/time icon to resolve the confusion, but this means we lose that quite useful functionality.

1 Like

Like I said.. please start new topics. Let’s just focus on this one UI bug here.

2 Likes

No problem and thank you for confirming the add event popup bug :slight_smile:

I thought I had in the past, but can’t find it. Will do now.

1 Like