OCPP IDTags expiry date does not match the configuration in the Steve portal about steve

[goekay]

ah, i know what you mean, the date sent in LocalAuthorizationList does not match the actual expiry date from database. this was to prevent a charging station to read from local/cached white list all the time, if for example the expiry is 5 years from now, and trigger it to ask Steve for the actual, up-to-date authorization status. in the settings tab, you can see an Expiration setting. it controls the time window for caching local id tags.

[goekay]

are you living in a country with utc+1 timezone?

[nuno407]

Yes. But the expiry date year does not match anyway

[goekay]

the thing is, steve, the java application, is set to use UTC as time zone. if your database's timezone varies from that, during the reading/writing such results might occur.

[goekay]

on the other hand, the LocalAuthorizationList message is not wrong. "16:44:14.689Z" denotes the time in UTC (because of "Z" as suffix), which translates to 17:43 (after rounding) in your time zone. so.. i don't get what the issue is here?

[nuno407]

Ok. Then the solution is to use UTC timezone in the database also?
Thank you for the help.

[goekay]

as a best practice: steve time zone == mysql time zone

but i do not see any problem with the LocalAuthorizationList mesasage. so there's no problem actually.

[goekay]

maybe it's time to rethink whether this limiting/strict behaviour is necessary...

[nuno407]

Hi @goekay,
Sorry for the not so fast response. But Yeap I think you fixed the issue.
Thank you! 😃