Nya SL Transport Departures fungerar inte korrekt vid sommartidsomställningen
Provar nu nya APIt mellan kl 1 och 2 på natten för att se om det klarar av tidsomställningen korrekt. Svaret är nej.
Jag har satt forecast=60 så jag förväntar mig att avgångar upp till en timme framåt ska listas, men APIt visar bara avgångar som avgår innan kl 02:00, resten saknas. Ju mer klockan närmar sig 2, desto färre avgångar syns i resultaten, oavsett vilken hållplats/station jag kollar på. Det gamla APIt tar korrekt med avgångar även efter kl 03:00.
Får jag föreslå att använda UTC-tid internt åtminstone överallt och endast visa lokal tid vid presentation, så bör det aldrig bli några fel. Hade gärna sett UTC-tid även i utdatan från APIt också, vilket underlättar vid t.ex. sortering på hösten när det blir omställning till vintertid igen då det lokal tid kommer finnas två stycken kl 2.
Bifogar två exempel vid Slussen vad det gamla APIt matar ut respektive det nya.
Jag har satt forecast=60 så jag förväntar mig att avgångar upp till en timme framåt ska listas, men APIt visar bara avgångar som avgår innan kl 02:00, resten saknas. Ju mer klockan närmar sig 2, desto färre avgångar syns i resultaten, oavsett vilken hållplats/station jag kollar på. Det gamla APIt tar korrekt med avgångar även efter kl 03:00.
Får jag föreslå att använda UTC-tid internt åtminstone överallt och endast visa lokal tid vid presentation, så bör det aldrig bli några fel. Hade gärna sett UTC-tid även i utdatan från APIt också, vilket underlättar vid t.ex. sortering på hösten när det blir omställning till vintertid igen då det lokal tid kommer finnas två stycken kl 2.
Bifogar två exempel vid Slussen vad det gamla APIt matar ut respektive det nya.
Följ inlägget
1
följare
Gamla APIt visar korrekt "15 min" medan det nya visar felaktigt "75 min". Intressant förresten också att expected time diffar med 18 sekunder mellan de två APIerna. Båda anropen gjordes exakt samma sekund.
Gamla APIt:
{
"GroupOfLine": null,
"TransportMode": "BUS",
"LineNumber": "697",
"Destination": "Stockholm C",
"JourneyDirection": 1,
"StopAreaName": "Edsvik",
"StopAreaNumber": 50506,
"StopPointNumber": 50506,
"StopPointDesignation": null,
"TimeTabledDateTime": "2024-03-31T01:54:41",
"ExpectedDateTime": "2024-03-31T03:01:16",
"DisplayTime": "15 min",
"JourneyNumber": 10128,
"Deviations": null
}
Nya APIt:
{
"destination": "Stockholm C",
"direction_code": 1,
"direction": "Stockholm C",
"state": "EXPECTED",
"display": "75 min",
"scheduled": "2024-03-31T01:54:41",
"expected": "2024-03-31T03:00:58",
"journey": {
"id": 2024033010128,
"state": "NORMALPROGRESS",
"prediction_state": "NORMAL"
},
"stop_area": {
"id": 50506,
"name": "Edsvik",
"type": "BUSTERM"
},
"stop_point": {
"id": 50506,
"name": "Edsvik"
},
"line": {
"id": 697,
"designation": "697",
"transport_mode": "BUS"
},
"deviations": []
}
Detta verkar ha lösts nu, och beror nog på bakomliggande realtidssystem som kan strula lite specifikt med trafik som blir försenad innan tidsskiftet men som ska avgå efter tidsskiftet, då förseningen skapas i en annan tidsoffset än själva avgången är.
Små skillnader mellan system beror nog på genom vilka system datat flödar i back-enden.
Hälsningar,
Bert
Och menar du "detta verkar ha lösts nu" som i att ni har hittat buggen/buggarna och fixat dessa så att det kommer bli rätt vid nästa tidsomställning eller bara snarare att problemet (uppenbarligen) inte händer dagar då det inte är tidsomställning?
Det gamla APIt verkar vara mer genomtänkt för tidsomställningar medan de som ligger bakom det nya verkar ha totalt ignorerat fenomenet samt alla buggar som bevisligen inträffar när det väl sker, vilket jag tycker är synd eftersom man kan ju tycka att nytt bör vara bättre.
Jag syftade på båda, som jag inte kan kan återskapa. Samtidigt så vet jag vad det nog berodde på och har det felanmälts till SL så att de kan åtgärda detta inför nästa tidsomställning. Jag kan dock inte lova att det är fixat (helt).
Hälsningar,
Bert
Ja det är ju bara under en timme per år man kan prova att återskapa problemet...