MST showing as +0900 instead of the "MST" value

support
21

I am experiencing the same issue – using the time format layout "2 Jan 2006, 3:04 PM MST". building the site on my laptop works fine and the TZ abbreviation shows up correctly (for example, 7 May 2024, 5:45 PM CEST) but building it on GH pages changes the TZ abbrev its offset 7 May 2024, 5:45 PM +0200.

I have read this entire thread but have gotten quite confused with how to actually remedy this what with all the mentions of Cloudflare and Netlify.

Any help specifically with GH pages would be much appreciated. I am using Hugo setup · Actions · GitHub Marketplace · GitHub

22

Which time zone are you in?

23

I am in CEST, but that shouldn’t matter, no? My template uses the following code so I expect it to format the dateStartOfEvent value correctly to whatever it is set. For this example, its value is “2024-05-07T17:45:00+02:00”

{{if ne $hour 0}}
    {{ .Params.dateStartOfEvent | time.Format "2 Jan 2006, 3:04 PM MST" }}
{{ end }}
24

That isn’t a time zone. A time zone is something like Europe/Lisbon. See:
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

25

ok thanks, but that still has nothing to do with the issue I am experiencing (in my understanding). Basically I want to render dateStartOfEvent: “2024-05-07T17:45:00+02:00” as 7 May 2024, 5:45 PM CEST (works fine on my laptop using Hugo 0.121) and not 7 May 2024, 5:45 PM +0200 (as it shows up on GH pages). In other words, I want to use the TZ abbreviation for the value of dateStartOfEvent

FWIW, my physical location is in Europe/Madrid and I want to use its abbrev CEST which may have nothing to do with what I am experiencing.

26

Yes, it does.

You need to set the TZ environment variable in your GitHub Pages workflow. If you don’t, the GitHub Pages runner uses its TZ, which is probably America/Los_Angeles or Etc/UTC (not sure).

27

ok, I think I understand what you are saying. However, I don’t want the GH Pages runner to always translate the timezone abbrev to CEST. I want it to use the abbrev for whatever the time might be in the dateStartOfEvent. So, for dateStartOfEvent: “2024-05-07T17:45:00+02:00”, the display should be 7 May 2024, 5:45 PM CEST, and for dateStartOfEvent: “2024-05-07T17:45:00+05:30” the display should be 7 May 2024, 5:45 PM IST (Indian Standard Time).

Is that possible?

28

No, it is not possible, because there is not a 1:1 relationship between time zone offsets and time zone abbreviation.

When you tell me you ate breakfast at 2024-04-27T06:01:03+02:00, I know when you ate, but I don’t know where you ate.

29

Gosh! of course, you are right (and why wouldn’t you be). I had never thought of it deep enough to realize this. So, the next question (thinking aloud) – how do I solve it? TZ offsets are not very intuitive, and as misleading as they may be, TZ abbrevs are “friendlier.” Perhaps I can solve it by converting all the timestamps to a specific TZ and using that TZ’s abbrev.

In any case, many thanks for your guidance. From hereon, I have to solve this on my own.

30

I don’t know of an easy way to do this. Stick to offsets.

If I tell you that I ate breakfast at 2024-04-27 06:11:34 CST, you have no idea when I ate breakfast, because the CST time zone abbreviation corresponds to any of these time zone offsets: -06:00, -05:00, or +08:00.

31

Thanks. What you say makes sense. As I said, as long as I convert all my timestamps to the same timezone, it should be ok. Perhaps using UTC will be a good compromise as it is not affected by daylight savings nonsense. It will be a bit more work for the international viewers of the info as they will have to figure out the time of the event in their local TZ, but that is unavoidable.