Open Treinfan opened 2 months ago
TLDR: I think this is a bug in HAFAS and that db-rest
cannot solve this in a clean way.
AFAIK – I might be wrong, or things might have changed by now! – all HAFAS requests (not responses) are timezone-unaware.
outDate
/outTime
request fields.{a,d}TZOffset
and translates {a,d}Time{S,R}
accordingly.hafas-client
has no other choice than working with what HAFAS has responded with (introduced here).db-rest
could tell hafas-client
to forcefully interpret the response fields in a specific (different) timezone, but it would have to know all stop IDs which to apply this to, otherwise it would accidentally
This is why I consider maintaining logic which decides which non-Europe/Berlin
stops to apply this transformation to as rather unsustainable.
I ran db-rest@6
locally with DEBUG=hafas-client
and then requested http://localhost:3000/journeys?from=7000616&to=7001369&via=&stopovers=true&language=nl&departure=2024-10-02T07:00:00%2b01:00
. (Just for clarity: I'm using a future date here to make sure my requests can be reproduced for a while, but the findings should be applicable nonetheless.)
We can see that
2024-10-02T07:00:00+01:00
is correctly sent as 20241002
/080000
, and{a,d}TZOffset
, so hafas-client
interprets them with Europe/Berlin
.First: Maybe there is a simple way to get HAFAS to behave like we want, e.g. upgrading to a newer protocol version?
We still haven't found out if we're just sending wrong requests to HAFAS or HAFAS responds with wrong responses. @Treinfan To investigate this thoroughly, you could
db-rest
, request journeys for that from
/to
/departure
, to see what HAFAS returns – Make sure to pick a departure
just before the last (second-last?) possible journey, to make sure that subsequent (wrong) journeys would still be within the results.If you do get (seemingly) wrong journeys back from db-rest
, try to vary from
/to
/departure
to see when the problem occurs.
Good luck!
TL;DR: the responses are correct, the requests should be changed
Yes, I can find such a schedule to help investigating this issue. Let's go for a travel advice from Crewe (7000616) to Inverness (7001204), with a date in the future (12th of December 2024). The local timezone is at that moment UTC+0. There is the daily Caledonian sleeper (a night train) that normally departs 23:45 local time from Crewe and arrives in Inverness 08:45 local time the next day. See the normal timetable of the operator. On the 12th of December a small change to the timetable applies, as Realtime Trains indicate: the departure time in Crewe will be 23:50 (local time) and the arrival time in Inverness 08:35 (local time). For now this seems not to be processed in the Hafas dataset, but those small changes may appear later.
Specifying departure time 23:12 + 02:00 (current timezone in Germany, now it is still daylight saving time) or Specifying departure time 23:12 + 01:00 (timezone in Germany on December 12th) shows the Caledonian Sleeper with the correct time and timezone (departure 23:45 +00:00 and arrival 08:45 +00:00).
"plannedDeparture": "2024-12-12T23:45:00Z",
"departureDelay": null,
"arrival": "2024-12-13T08:45:00Z",
"plannedArrival": "2024-12-13T08:45:00Z",
"arrivalDelay": null,
"reachable": true,
"tripId": "2|#VN#1#ST#1727296536#PI#0#ZI#196448#TA#0#DA#121224#1S#7001323#1T#2115#LS#7001204#LT#10845#PU#80#RT#1#CA#X70#ZE#5102#ZB# #PC#2#FR#7001323#FT#2115#TO#7001204#TT#10845#",
"line": {
"type": "line",
"id": null,
"fahrtNr": "5102",
"name": null,
"public": true,
"adminCode": "70CS-C",
"mode": "train",
"product": "regionalExpress",
"operator": {
"type": "operator",
"id": "caledonian-sleeper",
"name": "Caledonian Sleeper"
}
},
Specifying departure time 23:12 + 00:00 (timezone in UK on December 12th). The Caledonian Sleeper is not visible (but it should be). The first advice starts with a bus departing at 00:44:
"departure": "2024-12-13T00:44:00Z",
"plannedDeparture": "2024-12-13T00:44:00Z",
"departureDelay": null,
"arrival": "2024-12-13T01:59:00Z",
"plannedArrival": "2024-12-13T01:59:00Z",
"arrivalDelay": null,
"reachable": true,
"tripId": "2|#VN#1#ST#1727296536#PI#0#ZI#200695#TA#0#DA#131224#1S#7000616#1T#44#LS#7001537#LT#159#PU#80#RT#1#CA#Bsv#ZE#56119#ZB#Bus56119#PC#3#FR#7000616#FT#44#TO#7001537#TT#159#",
"line": {
"type": "line",
"id": "bus56119",
"fahrtNr": "56119",
"name": "Bus56119",
"public": true,
"adminCode": "70NT-S",
"productName": "Bus",
"mode": "train",
"product": "regional",
"operator": {
"type": "operator",
"id": "northern",
"name": "Northern"
}
},
Specifying departure time 22:12 + 00:00 (timezone in UK on December 12th) Just to verifiy that the caledonian sleeper is shown if I specify a departure time one hour earlier:
"departure": "2024-12-12T23:45:00Z",
"plannedDeparture": "2024-12-12T23:45:00Z",
"departureDelay": null,
"arrival": "2024-12-13T08:45:00Z",
"plannedArrival": "2024-12-13T08:45:00Z",
"arrivalDelay": null,
"reachable": true,
"tripId": "2|#VN#1#ST#1727296536#PI#0#ZI#196448#TA#0#DA#121224#1S#7001323#1T#2115#LS#7001204#LT#10845#PU#80#RT#1#CA#X70#ZE#5102#ZB# #PC#2#FR#7001323#FT#2115#TO#7001204#TT#10845#",
"line": {
"type": "line",
"id": null,
"fahrtNr": "5102",
"name": null,
"public": true,
"adminCode": "70CS-C",
"mode": "train",
"product": "regionalExpress",
"operator": {
"type": "operator",
"id": "caledonian-sleeper",
"name": "Caledonian Sleeper"
}
},
I just have updated my previous reply with all examples. It seems that the returned timetable is fully correct, so probably the requests should be changed to solve the time difference between what I want to request and what is returned.
Hi,
I have been using your API for a while now with success, but I have noticed some strange behaviour when planning journeys inside the UK. Despite the timezone parameters being correct and the returned data being correct, the advices are shown for one hour later than requested. For example, this request, departure time 07:00+01:00 doesn't show the trains departing at 06:56+01:00 and 07:21+01:00, but gives the trains departing at 08:21+01:00, 09:21+01:00 and 10:05+01:00. I can see that the timezone in the parameter is processed, because 08:00+02:00 gives exactly the same result as 07:00+01:00.