[doc] Timezone and daylight saving time precisions #34
Conversation
prhod
force-pushed
the
tz_daylight-saving
branch
from
00db60a
to
2076413
Compare
|
|
||
| The `network_timezone` field in file networks.txt sets the time zone for all `stop_times` of a `trip` in the `network`. | ||
|
|
||
| If a feed covers multiple time zones, a specific time zone information can be specified on a `stop_point` in the `stop_timezone` field. Set this optional field in file `stops.txt` (for stops with location_type = 0). If not set, the timezone of the network is used. Ensure that trip travel times remain accurate and consistent by providing departure and arrival times based on the `network_timezone` for stops that are out of that timezone. |
There was a problem hiding this comment.
I think the stop_timezone field is not used at all inside kraken/loki.
We always use the network_timezone for all stop_times of a vehicle journey.
Note that allowing different timezone on each stop_time would make it harder to check if the stop_times are increasing along a trip.
There was a problem hiding this comment.
This chapter tries to describe the actual (kraken) way of dealing with TZ, and seems to be similar to what you are saying. Maybe the text is not clear enough?
| - NTFS uses the local timezone at noon of the travel day of the trip, following the same rule as (GTFS Time data format)[http://gtfs.org/schedule/reference/#field-types]: | ||
| > Time in the HH:MM:SS format (H:MM:SS is also accepted). The time is measured from "noon minus 12h" of the service day (effectively midnight except for days on which daylight savings time changes occur). For times occurring after midnight, enter the time as a value greater than 24:00:00 in HH:MM:SS local time for the day on which the trip schedule begins. \ | ||
| Example: 14:30:00 for 2:30PM or 25:35:00 for 1:35AM on the next day. | ||
|
|
There was a problem hiding this comment.
I think it would be great to have a documented upper bound
| The maximum accepted value is 48:00:00 |
There was a problem hiding this comment.
If I remember correctly, there are some trains that runs more than 2 days. Is limit of 48:00 a technical limit ?
This PR is adding precisions on timezone aware NTFS and daylight saving time handling in stop_times.