-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
airDatepicker shifts time by loosing timezone information #643
Comments
I'm having a similar issue when calling updateAirDateInput(
inputId = "theDateInput",
value = input$theDateInput
) Which should not change the value, but if the server and client timezones are different, the value will keep shifting the datetime at every call. Different timezones between server and client can be tested locally by running a rocker image with the app, which is set to UTC by default. The shiny client will pick your local timezone from the browser. |
Hello, Victor |
I'm using release 0.8.0 of shinyWidgets.
I encountered the following issue:
I set the initial value of a
airDatepicker
withlubridate::now()
. Then I immediately read out the value without interacting in any way with the widget. The returned value is different from the original value. Example (first line initial value, second line retrieved value):Note the two hour shift.
I tracked this down to
anytime::anytime
. When setting the initial value,dayjs
converts the time to the local time of the client, which seems desirable, because the user is not confused. When reading out the value,dayjs
still returns a local time with a timezone offset.See here and here.
This string is then passed to
anytime::anytime
, which ignores the timezone offset and simply uses - I presume - the server timezone.See here.
lubridate
on the other hand does the right thing.I have not found a way to make
anytime::anytime
respect the timezone shift. I would also not be in favour of changing thedayjs
part to UTC, because I want my users to see their local time. Ifanytime
cannot be coerced into proper cooperation, I would suggest a switch to another library likelubridate
.Disclaimer: I'm not familiar with the intricacy of date formating, but the timezone offset is also part of ISO8601. So I would take libraries, which silently ignore the timezone shift, with a lot of caution.
The text was updated successfully, but these errors were encountered: