-
Notifications
You must be signed in to change notification settings - Fork 26
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
Setting departure times and dealing with time zones #188
Comments
Hi James. Thanks for opening this issue. It seems that In any case, this needs to be clarified in the |
Hi James. We have dealt with this issue in the past, and you can see an example here. @rafapereirabr is right about R5's approach, but there was a bug in the very early versions of r5r that caused time zones to be mixed up. Our approach to fix it was to always use the time zone of the study area, regardless of the time settings of the user's computer, thus in line with R5. In your case, 8 am always will mean 8 am in Portland. If I remember well, @dhersz is the one who fixed this bug at the time. |
That's exactly it, r5r:::posix_to_string(as.POSIXct("13-05-2019 14:00:00", format = "%d-%m-%Y %H:%M:%S"))
#> $date
#> [1] "2019-05-13"
#>
#> $time
#> [1] "14:00:00"
r5r:::posix_to_string(as.POSIXct("13-05-2019 14:00:00", format = "%d-%m-%Y %H:%M:%S", tz = "America/Montreal"))
#> $date
#> [1] "2019-05-13"
#>
#> $time
#> [1] "14:00:00" Which means that in @jamesdeweese 's case it's using Portland timezone, not Montreal. Perhaps the easiest way of setting the timezone based on your own timezone is using portland_dt <- lubridate::with_tz(
as.POSIXct("13-05-2019 14:00:00", format = "%d-%m-%Y %H:%M:%S", tz = "America/Montreal"),
tzone = "America/Los_Angeles"
)
r5r:::posix_to_string(portland_dt)
#> $date
#> [1] "2019-05-13"
#>
#> $time
#> [1] "11:00:00" I'll adjust the documentation to reflect this. |
Done in 1ace260. The documentation of
|
Thanks @dhersz @mvpsaraiva @rafapereirabr! Really appreciate it. This answers my question exactly. And I think the explanation on datetime parsing in the docs is clear. Thanks again. |
Thank you for filing the issue and for the feedback! |
Wondering how time zones are dealt with when passing departure times to r5r. I'm running a travel-time matrix for Portland, Oregon, but I'm located in Montreal. My computer is set to Montreal time (3 hours ahead). I want to be certain that when I select a 7 a.m. (07:00) departure time when running travel_time_matrix() or detailed_itineraries(), that I'm getting 7 a.m. clock time in the area being studied--in this case, Portland.
Are POSIXct date-time objects being converted to clock time automatically based on the GTFS time zone? Is it based on the computer's system time? Or does the time zone need to be set manually when creating the departure_datetime object using, e.g., tz = "America/los_angeles", when the study area and computer's setting are different?
I wasn't entirely sure from the documentation and two previous issues related to time zones that I saw on GitHub. When I tested by manually setting different time zones, I get precisely the same travel time matrix. I would expect them to yield different results. I retested it with the built-in dataset and example from the Intro. Same unexpected result. I've pasted that reproducible code below.
Both travel-time matrices are identical, but the departure_datetimes are not.
The text was updated successfully, but these errors were encountered: