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]

Timezone bug with GMT?

Product Support

JammyDodger May 5, 2022, 6:53am 2

I think this has cropped up before:

Topic		Replies	Views
Flip display of timezones Feature	3	1146	February 16, 2022
Conflict between timezones in "Insert date / time" UX	3	696	November 8, 2021
Etc/GMT+4 seems to be GMT-4 Bug	1	326	April 9, 2024
Timezone woes - always defaults to America/Denver Product Support	0	558	November 27, 2021
Local-dates: dates show days in the future Bug	6	840	June 6, 2019

Timezone bug with GMT?

Related topics