Timezone bug with GMT?

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

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:

it results in the wrong time:

2022-05-05T18:00:00Z

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

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:

1 Like

I think this has cropped up before:

5 Likes

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.

2 Likes

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: