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.
It also has a selector for the source timezone, but that doesn't work, for reasons I've forgotten. I think that part was intended to allow me to see times without tz data included, reinterpreted as being from other tzs, but I never ended up using it enough to fix.
I made this because I often read some logs, thought "hmm when was this again?", then typed "UTC to EDT" into a new tab, and then ended up on some ad-loaded page that with dropdowns to select things like the year. I don't want dropdowns! I've already got a timestamp. I made this over a year ago and I use it 2-3x/week.
1 - https://wcarss.ca/tz