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
So it seems like generally a goodidea to use UTC on the backend, but I have a couple particular reasons:
Since GTFS is set to the agency's timezone, clients are expected to query in the "right timezone" of the agency. This works fine if the client is in the same region, but breaks if the client is outside the agency's timezone. Me checking BART in Indiana returns different results than someone checking it in California.
Providence uses Time.now to determine whether to request real-time departures, so the timezone of the server matters. This could be a problem, since one host runs multiple agencies, but the containers server components run in have their own timezone. A container's timezone defaults to UTC.
I think that the necessary steps would be to:
translate stop times in Timetable from the the agency timezone to UTC
configure clients / providence to use UTC for all time-related queries
(future-proofing) configure providence's agency.rb to know the agency's timezone. I imagine some future real-time applications will need to know the local agency time.
clarify the request timezone in this repo
The text was updated successfully, but these errors were encountered:
I completely agree with this. Timezones should only be dealt with on the client side.
This also clears up issues with DST for everything after the initial parse of GTFS source. The GTFS spec says:
The time is measured from "noon minus 12h" (effectively midnight, except for days on which daylight savings time changes occur) at the beginning of the service date."
Timetable can easily parse the GTFS source with this strategy, converting all times to UTC for everything downstream to use.
I remember we said at some point that agency information would be available through meta.agency.* or something like that. Timetable should probably be the primary source for that, so another addition from this will be creating that RPC.
So it seems like generally a good idea to use UTC on the backend, but I have a couple particular reasons:
Time.now
to determine whether to request real-time departures, so the timezone of the server matters. This could be a problem, since one host runs multiple agencies, but the containers server components run in have their own timezone. A container's timezone defaults to UTC.I think that the necessary steps would be to:
agency.rb
to know the agency's timezone. I imagine some future real-time applications will need to know the local agency time.The text was updated successfully, but these errors were encountered: