I made a crappy little web tool[1] that lets me paste a timestamp into it, and will show me that time in my current timezone by default (I think that's just hardcoded haha), or in another one that I select. I mostly use it when reasoning about logs -- for some reason my mind has never gotten used to mapping UTC time to my time. It also has a selector for the source timezone, but that doesn't work, for reasons I've fo…
Cool simple tool! :) I think the reason the source zone might not work (and I'm not an expert, and date times in code are hard), is that all "timestamps" are in Zulu / GMT0 time, so it won't make sense if you try to source a Zulu time from like Hawaii time or whatever.
It seems to have actually been a typo-misuse of moment.tz's very similar but very different constructor patterns. To illustrate, imagine we have a date "2020-01-01", an offset tz "America/Vancouver", and "America/Toronto" as the locale's timezone.
moment(date).tz(offset) says "interpret date in its given tz, falling back to the locale tz if not given, then reinterpret it via the offset tz". So the date "2020-01-01" with no encoded tz data is interpreted as midnight in the locale's tz, America/Toronto. That is then reinterpreted in the offset timezone America/Vancouver, so calling .format() on it gives the result "2019-12-31T21:00:00-08:00" -- midnight on New Year's Eve in Toronto was 9 PM on Dec 31st in Vancouver. Offset here is changing the output, not the input.
moment.tz(date, offset) says "interpret date in its given tz, falling back to offset as the tz if not given". So the date "2021-01-01" with no tz data is interpreted as midnight in the offset tz, "America/Vancouver". Now calling .format() gives "2020-01-01T00:00:00-08:00", or midnight in Vancouver, which would be 3 AM in Toronto.
Glad to have it fixed.