Howdy,
I’m having some trouble understanding how Hugo handles dates. Converting date strings does not seem to be consistent.
Converting strings with the time
function yields at random different results:
convert 2022-05-31T16:30:00+01:00 -> 2022-05-31 16:30:00 +0100 +0100
convert 2022-07-26T16:30:00+01:00 -> 2022-07-26 16:30:00 +0100 +0100
convert 2022-03-18T17:00:00+01:00 -> 2022-03-18 17:00:00 +0100 CET
convert 2022-06-24T17:00:00+01:00 -> 2022-06-24 17:00:00 +0100 +0100
convert 2022-09-23T17:00:00+01:00 -> 2022-09-23 17:00:00 +0100 +0100
convert 2022-11-25T17:00:00+01:00 -> 2022-11-25 17:00:00 +0100 CET
convert 2022-03-19T12:00:00+01:00 -> 2022-03-19 12:00:00 +0100 CET
convert 2022-06-25T12:00:00+01:00 -> 2022-06-25 12:00:00 +0100 +0100
convert 2022-09-24T12:00:00+01:00 -> 2022-09-24 12:00:00 +0100 +0100
convert 2022-11-26T12:00:00+01:00 -> 2022-11-26 12:00:00 +0100 CET
convert 2022-05-03T18:00:00+01:00 -> 2022-05-03 18:00:00 +0100 +0100
convert 2022-05-05T18:00:00+01:00 -> 2022-05-05 18:00:00 +0100 +0100
Why does it sometimes use +0100 CET
vs +0100 +0100
?
Problem is: when I add some duration to the dates, the resulting timezone is different which is wrong!
If I add 2 hours to the +0100 +0100
timezone, I end up with +0200 CEST
when I really want +0100 CET
.
start=2022-03-19 12:00:00 +0100 CET add=7h -> 2022-03-19 19:00:00 +0100 CET%!(EXTRA time.Time=2022-03-19 19:00:00 +0100 CET)
start=2022-05-05 18:00:00 +0100 +0100 add=2h -> 2022-05-05 21:00:00 +0200 CEST%!(EXTRA time.Time=2022-05-05 21:00:00 +0200 CEST)
Any ideas how to solve this? Thanks.
I don’t know the convert function. Or is that some form of typographic help to show what happens? Then please post the layout that does the conversion. Then post the frontmatter that is converted. Also post the setup for your timezone. I remember some months back there was a similar issue that ended up being in connection to timezones and the fact, that the time
function does NOT create a string but a time-object representation that you print with $result.Format()
.
So basically: telling us what you see on your computer won’t help. Tell us how to re-create the issue on our own will help. But maybe the whole .Format thing will help already.
Also 1h/2h issues in CET? Summertime maybe?
Thanks for the replies. As I said, I simply convert datetime strings using the time
function, that’s why I posted both input and output from this one call.
The code is trivial:
{{ range $i, $page := $pages }}
{{ with $page.Params.dates }}
{{ range . }}
{{ $date := time . }}
{{ warnf "convert %s -> %s" . $date }}
{{ end }}
{{ end }}
{{ end }}
The posted output shows the input datetime strings and the resulting time object from the conversion. The input is a string, the output a time object.
I’ve specified the timezone in the config:
timeZone = "Europe/Berlin"
Makes no difference if I add a parameter to the time function.
The input datetime strings look exactly the same to me, yet the resulting timezones seem to be different. They sure behave differently when I try to work with them. To me it seems like a problem with the time
function.
Stupid. Now I understand what is going on. Depending on the date, Hugo (correctly) uses either wintertime or summertime (CET vs CEST) and it is wrong that all datetime strings specify the same time offset (CET).
Also: Stupid I said somewhere that time
creates an OBJECT that you need to run through .format
to get it into a string. If you just print the object then GoLang (not Hugo) outputs something that it thinks is right.
By the way, it’s only stupid the first time you do it wrong
{{ $format := "Mon, 02 Jan 2006 15:04:05 -0700" }}
{{ range $i, $page := $pages }}
{{ with $page.Params.dates }}
{{ range . }}
{{ $date := time . }}
{{ warnf "convert %s -> %s" . ($date.Format $format) }}
{{ end }}
{{ end }}
{{ end }}
The conversation really helped Thanks for your time!
1 Like