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: [图片] 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: [图片]

GMT时区错误？

产品支持

JammyDodger 2022 年5 月 5 日 06:53 2

我认为这个问题以前出现过：

话题		回复	浏览量
Flip display of timezones Feature	3	1154	2022 年2 月 16 日
Conflict between timezones in "Insert date / time" UX	3	708	2021 年11 月 8 日
Etc/GMT+4 seems to be GMT-4 Bug	1	327	2024 年4 月 9 日
Timezone woes - always defaults to America/Denver Product Support	0	564	2021 年11 月 27 日
Local-dates: dates show days in the future Bug	6	856	2019 年6 月 6 日

GMT时区错误？

相关话题