Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Datetimes issues (UTC vs local time) #20

Open
adelcasse opened this issue Nov 13, 2020 · 2 comments
Open

Datetimes issues (UTC vs local time) #20

adelcasse opened this issue Nov 13, 2020 · 2 comments

Comments

@adelcasse
Copy link

As far as I know (we didn't test much and went to the easier solution on our side), Navitia returns datetimes as "YYYYMMDDTHHMMSS".

As implemented here with the time.Parse function, datetimes are parsed as if they were UTC https://github.com/govitia/navitia/blob/master/types/json.go#L23 instead of the correct local time.

In our fork of the library, we've used time.ParseInLocation to get the correct timezone (but it's hardcoded to our use cases only in France with "Europe/Paris" ;))

The correct way might be to use the "context" given by navitia on every endpoint response (https://doc.navitia.io/#other-objects) with the timezone in it, and then use ParseInLocation with this timezone. But this would probably have quite a big impact on everything related to unmarshalling in the library, as it's returned aside of the types themselves.

What do you think ?

@thomas-tacquet
Copy link
Contributor

As navitia returns timezones it's a good idea to use it directly while Unmarshalling messages.

To avoid breaking changes I suggest to duplicate every structure member having a time.Time type.

For exemple :

type Example struct {
	BeginTime time.Time
}

Will be changed to :

type Example struct {
        // BeginTime value will not change
	BeginTime time.Time
        // but VALUE_NAME_Localized will be parse using Location given by navtitia
        BeginTimeLocalized time.Time
}

What do you thnik about this design ?

@adelcasse
Copy link
Author

We can do this yes, it's a good idea (even if I think it's a bug to have an incorrect date, but it's probably better like this if other users of the library had workarounds on this).

Concerning design, I think the most important thing will be to define how we'll pass the timezone context to the unmarshaller, as timezone is not directly in the unmarshalled data but in another JSON node of the response (not inside journeys but inside a separate "context" node directly in the root of the response).

(I'm speaking about journeys here because we only use that on our side, but it's probably the same in other requests with datetimes)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants