Time zone behaviour might not be as expected
Closed this issue · 8 comments
Perhaps this is completely intentional and just needs clarification on the web page itself, but time zones work opposite from how I would expect them to work. If I put in 23/09/2021 23:00:00 Europe/London, being in Europe/Amsterdam myself, I would expect the tool to interpret the time as being in the selected time zone and generate a proper timestamp based off of that, so all output fields would come together to say that the selected time is 24/09/2021 00:00:00 or Unix timestamp 1632434400. Instead, the time is always taken as being from my time zone, and it is being converted to another time zone, so in the above example the actual output is 23/09/2021 22:00:00 or Unix timestamp 1632430800.
👍
As a concrete example, someone in my discord asked "what time is the Nintendo direct tomorrow?" I had expected to plug in 9/23/2021, 3:00PM, US/Pacific and get the correct timestamp. However, I instead received the timestamp 1632427200, corresponding to 9/23/2021, 3:00PM, US/Central, which happens to be my timezone.
My suggestion would be that the timezone field at the top of the page adjusts the timezone component of the input date and time and that there is a second timezone selector that adjusts the timezone of the example results
@mgway that happens to be exactly the reason I found this 😄
I was probably too tired when implementing this, I thought the way you described it is how it was already working, you're supposed to be able to input the date, time and timezone, then all the previews would show the time from that timezone in your local time, but that indeed isn't what's happening, I'll take a closer look.
I'm not a moment expert but I've worked through a fair share of issues with timezones in python. I suspect that the issue comes from https://github.com/DJDavid98/HammerTime/blob/main/src/components/TimestampsTable.tsx#L72, the first argument is a moment() which by default has the local timezone attached, so updating the timezone causes the time to be shifted instead of only replacing the timezone component as alluded to in the docs https://momentjs.com/timezone/docs/#/using-timezones/parsing-in-zone/
The changes are live, please give it a try, from my testing it seems to actually do what I would expect now
It does seem correct now, thanks for the quick fix! Though I think there has been a regression where non-US locales now get the US format in the date and time picker (MM/DD/YYYY HH:mm:ss a)...
You're seeing an intentional change in response to #8, the picker now comes from the user's browser and uses whatever locale it is configured for. This was the simplest compromise I could make to allow typing in time values. It's also why the input is now split between date and time separately, because the combined datetime input is still not supported widely enough.
Hell of a way to find out my browser locale was en-US 😄 thanks for the heads-up