I’m not sure whether this is a bug or I’m misunderstanding the behavior. Example 1 Code: [date=2022-05-06 time=01:00:00 timezone="America/Los_Angeles"] (Los Angeles is GMT-7.) Result: 2022-05-06T08:00:00Z (UTC) Example 2 Code: [date=2022-05-06 time=01:00:00 timezone="Etc/GMT-7"] Result: Los Angeles is GMT-7. If we say, “The event is at 1pm in the timezone GMT-7” (Los Angeles timezone), and someone uses GMT-7 in Discourse like this: [image] it results in the wrong time: 2022-05-05T18:00:00Z (UTC) To get Los Angeles time there (GMT-7), you have to enter GMT+7 like this: [date=2022-05-06 time=01:00:00 timezone="Etc/GMT+7"] Result: 2022-05-06T08:00:00Z (UTC) Shouldn’t America/Los_Angeles+7 be the same as GMT, and GMT-7 be the same as America/Los_Angeles? The widget also says 1pm in GMT-7 is different from LA: [image]

I think this has cropped up before: [image] Conflict between timezones in "Insert date / time" UX I’m afraid the technical reason here is pretty confusing - you can read about it at Moment Timezone | Docs POSIX compatibility requires that the offsets are inverted. Therefore, Etc/GMT-X will have an offset of +X and Etc/GMT+X will have an offset of -X . This is a result of IANA’s Time Zone Database and not an arbitrary choice by Moment.js. Thus, using locality based identifiers is preferred over fixed-offset identifiers. So, in IANA’s Time Zone database, Europe/Oslo is currently equivalent…

Thanks, I searched before I posted but didn’t see that discussion. I think it would be clearer for users if it were shown without the Etc/ prefix, and GMT-7 were the same as America/Los_Angeles, but I guess that would cause surprises for people who are already doing something with the dates programmatically.

I think it’s quite easy to overlook that Los_Angeles and GMT-7 aren’t the same thing. LA is in either PDT (GMT-7) or PST (GMT-8) depending on the time of year, and the clock changes occur in different countries at different times (UK: last Sunday in March and last Sunday in October, vs US second Sunday in March and first Sunday in November) so the offset will vary. That’s why date/time systems usually show both the time zone and the offset.

Thanks, we’re aware of the clock changes, but people who do find GMT-7 (or GMT-8 at another time of the year) in the timezone picker might not realize that the dates they entered aren’t what they intended. Or when they see something like this, it won’t make sense, because LA is GMT-7 at the moment: [image]

Problème de fuseau horaire avec GMT ?

Assistance produit

JammyDodger Mai 5, 2022, 6:53 2

Je pense que cela s’est déjà produit :

Sujet		Réponses	Vues
Flip display of timezones Feature	3	1146	Février 16, 2022
Conflict between timezones in "Insert date / time" UX	3	696	Novembre 8, 2021
Etc/GMT+4 seems to be GMT-4 Bug	1	326	Avril 9, 2024
Timezone woes - always defaults to America/Denver Product Support	0	558	Novembre 27, 2021
Local-dates: dates show days in the future Bug	6	840	Juin 6, 2019

Problème de fuseau horaire avec GMT ?

Sujets connexes