Wrong date_time for cross midnight trips (GMT offset issue) about navitia HOT 5 CLOSED

Merci!

J'ajoute le lien vers le ticket interne, sinon on va l'oublier: http://jira.canaltp.fr/browse/NAVITIAII-1872

from navitia.

Hi @xavierraffin , sorry for the late response but I have one good and one bad news.

The good news is (at least for me 😌 ) there is no UTC bug 😉

The bad news is there is a quite a huge bug in the route schedule API when called with a calendar.
Simply said, we shouldn't have any dates in the result (it does not have any meaning).

For /stop_schedules what we do is:
when called with only a datetime we have the stop_schedule from this datetime:
(Note: all following examples are done with you dataset):

/stop_points/stop_point:2/stop_schedules?from_datetime=20160704T011000

stop_schedules": [{
...
date_times": [
{ "date_time": "20160716T020500",},
{ "date_time": "20160716T030500",},
{ "date_time": "20160717T010500",}
]}]

Note: the default is to limit to 24h, so the 3rd datetime is the next day at 01:05 since we ask for the departure after 01:10

when called with a calendar you don't get date, only time (the date is not relevant since you ask for the schedule for say all weekends):
/stop_points/stop_point:2/stop_schedules?calendar=Y2FsZW5kYXI6OA

stop_schedules": [{
...
date_times": [
{ "date_time": "010500"}
{ "date_time": "020500"}
{  "date_time": "030500"}
]}]

Note: the date_time are sorted compared to midnight

If you want another sort (eg, you want the first date_time to be after 02:00), it's not straight forward, but you can use the same from_datetime parameter:

Note: this is not great because this param is then used quite differently as it's primary purpose, and the API requires it to be a datetime even if only the time will be used. I would be to change the API to accept only time when given a calendar parameter.

/stop_points/stop_point:2/stop_schedules?from_datetime=20160716T020000&calendar=Y2FsZW5kYXI6OA:

stop_schedules": [{
...
date_times": [
{  "date_time": "020500"}
{  "date_time": "030500"}
{  "date_time": "010500"}
]}]

Is this behaviour ok with you ?

I think the /route_schedules API should have the same behaviour, but it is not the case, the date is dumped when a calendar parameter is provided.

Is it ok for you if we change the /route_schedules API ? It will not break the API in the strict sens, but it can break you integration (I don't think it is used with calendar in our side).

Side note: the fact that with your call the datetime are sorted with this order:
/routes/route:1_A/route_schedules?from_datetime=20160704&calendar=Y2FsZW5kYXI6OA&show_codes=true

date_times": [
{    "date_time": "20160702T025000",},
{    "date_time": "20160703T005000",},
{    "date_time": "20160703T015000",}

is due to the fact that you do not provide an our in you parameter from_datetime=20160704, thus 00:00 is considered.
This date is then wrongly changed in UTC (this is the behaviour we want when no calendar is provided) to 02:00), thus you get first 0250, then 0050 0150
we'll need to stop shifting the from_datetime param to UTC when a calendar is provided since in that case, only local time is relevant.

from navitia.

Is this behaviour ok with you ?

That's OK for me.
Lot of good ideas and intentions here.
Nevertheless changing from "YYYMMddThhmmss" to "YYYMMdd" is a little bit misleading.
Date format consistence may be more important than date insignificance (Stephan agree last month ) ?
Note that in that case I understand why, I just ask for my "navitia culture".
You'll stay like that for v2 api ?

Note: the default is to limit to 24h

Is there a parameter to increase it ?

Is it ok for you if we change the /route_schedules API ?

Yes that sounds good but I have few questions

• Does it means that you'll change "date_time" format from "YYYMMddThhmmss" to "YYYMMdd" ?
• if I understand well, youre correction consist only to stop the UTC shift when a calendar is given to route_schedules ?
  I mean are you sure it will be enough ?

I tried to add an hour on my request (version 1.20), and nothing changes

http://srv-dev04/v1/coverage/tisseo_fh/routes/route:1_A/route_schedules?from_datetime=20160704T033000&calendar=Y2FsZW5kYXI6OA&show_codes=true

return the same than

http://srv-dev04/v1/coverage/tisseo_fh/routes/route:1_A/route_schedules?from_datetime=20160704&calendar=Y2FsZW5kYXI6OA&show_codes=true

date_times": [
{    "date_time": "20160702T025000",},
{    "date_time": "20160703T005000",},
{    "date_time": "20160703T015000",}

from navitia.

Nevertheless changing from "YYYMMddThhmmss" to "YYYMMdd" is a little bit misleading.
Date format consistence may be more important than date insignificance (Stephan agree last month ) ?
Note that in that case I understand why, I just ask for my "navitia culture".
You'll stay like that for v2 api ?

hum no we'll change from YYYMMddThhmmss to hhmmss (or Thhmmss I need to check the standard), but only for calendar's route_schedules
and I do agree that it does not seems straight forward, I think in the v2, we'll split it in 2 fields, one optional date and the time.

Is there a parameter to increase it ?

yes duration

Yes that sounds good but I have few questions
Does it means that you'll change "date_time" format from "YYYMMddThhmmss" to "YYYMMdd" ?

no we'll change it to hhmmss

if I understand well, youre correction consist only to stop the UTC shift when a calendar is given to route_schedules ?
I mean are you sure it will be enough ?

No the correction is a bit more complex, we need to change the /route_schedules API behaviour to be more consistent the the /stop_schedule's:

• refacto the api's route_schedules.cpp file to do like /stop_schedules
• change date_time format
• do not shift from_datetime parameter in UTC if a calendar is provided

I'm not 100% sure it will be enough, I need to test, but if the stop_schedule behaviour is OK with you, I think it will be ok.

I tried to add an hour on my request (version 1.20), and nothing changes

strange, I'll look into it, but it is not that surprising, since I think the route_schedule.cpp code is not correct to do exactly like stop_schedule.cpp

from navitia.

Great !
Good luck

Yes that sounds good but I have few questions
Does it means that you'll change "date_time" format from "YYYMMddThhmmss" to "YYYMMdd" ?

no we'll change it to hhmmss

Of course (copy paste error)

from navitia.