4 ms·

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 har

by wcarss 5y ago

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 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 https://wcarss.ca/tz

sarimabbas 5y ago
i made something similar that lets you map times between arbitrary timezones: http://getwaqt.netlify.app/ http://getwaqt.netlify.app/. thanks for sharing!
nicoburns 5y ago
Yeah, nice benefit of living in the UK is local time is at most one hour out from UTC. Downside is it's easy to code timezone bugs in winter and not notic until summer!
graderjs 5y ago
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.
- wcarss 5y ago
  That was a good guess! Your comment provided some helpful motivation to go look into it. :) 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.
  - graderjs 5y ago
    Awesome!

by wcarss 5y ago

sarimabbas 5y ago

i made something similar that lets you map times between arbitrary timezones: http://getwaqt.netlify.app/ http://getwaqt.netlify.app/. thanks for sharing!

nicoburns 5y ago

Yeah, nice benefit of living in the UK is local time is at most one hour out from UTC. Downside is it's easy to code timezone bugs in winter and not notic until summer!

graderjs 5y ago

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.

wcarss 5y ago
That was a good guess! Your comment provided some helpful motivation to go look into it. :) 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.
- graderjs 5y ago
  Awesome!