You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It'd be great to set the timezone instead of it defaulting to UTC. In my case, I need to store the selected date/time in a variety of possible time zones, and the user is simply selecting the date/time according to their local time. To adjust the selected date/time value is rather arduous: I have to recognize their tz, modify the UTC output by the correct number of hours (while keeping it in UTC), and then convert it to their local time zone. For instance, a user in america/los_angeles may select a date of 2023-12-25. But when I convert the output directly to the pacific time zone it becomes 2023-12-24.
The text was updated successfully, but these errors were encountered:
If you install from GitHub, there's now a tz = argument in airDatepickerInput() and updateAirDateInput(), let me know how it works for you if you test it.
the initial time is converted to the user's local time regardless of tz option
the tz option is only used to parse the datetime string returned from the picker
So that means it is impossible to set the initially selected time with this library, without knowing the user's timezone. I imagine this will be a problem for many apps that rely on time selection, unfortunately.
I see two ways to make this work:
the local time zone conversion step in the browser is removed or made optional
the returned datetime includes the user's timezone
Either of these options would allow an app author to get a consistent result from the picker regardless of user timezone.
OK, I think I found a workaround-- as long as you pass value as a character rather than POSIX, then there's no initial time zone conversion. That allows you to control the result from airDatepickerInput.
It'd be great to set the timezone instead of it defaulting to UTC. In my case, I need to store the selected date/time in a variety of possible time zones, and the user is simply selecting the date/time according to their local time. To adjust the selected date/time value is rather arduous: I have to recognize their tz, modify the UTC output by the correct number of hours (while keeping it in UTC), and then convert it to their local time zone. For instance, a user in america/los_angeles may select a date of 2023-12-25. But when I convert the output directly to the pacific time zone it becomes 2023-12-24.
The text was updated successfully, but these errors were encountered: