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

Date handling in OCPP operations #1477

Open
4 tasks done
jerome-benoit opened this issue Jun 6, 2024 · 3 comments
Open
4 tasks done

Date handling in OCPP operations #1477

jerome-benoit opened this issue Jun 6, 2024 · 3 comments

Comments

@jerome-benoit
Copy link

jerome-benoit commented Jun 6, 2024

Checklist

  • I checked other issues already, but found no answer/solution
  • I checked the documentation and wiki, but found no answer/solution
  • I am running the latest version and the issue still occurs
  • I am sure that this issue is about SteVe (and not about the charging station software or something unrelated to SteVe)

Specifications

SteVe Version     : 3.6.0

Description

The date input in several forms for OCPP operations is not translated to the UTC in the payload. The OCPP server time stamping is already correctly using UTC.
The charging station expects date in UTC after translation of the input date from the CSMS timezone to the charging station timezone. The timezone information is not expected to be part of it.

SetChargingProfile, ReserveNow and UpdateFirmware operations are impacted. The later is not possible since the input check for date in the future if you're running the CSMS on a GMT+X timezone.

@goekay
Copy link
Member

goekay commented Jun 7, 2024

if you're running the CSMS on a GMT+X timezone.

so, you are running steve not in the default (i.e. UTC) but some other timezone?

@jerome-benoit
Copy link
Author

jerome-benoit commented Jun 7, 2024

if you're running the CSMS on a GMT+X timezone.

so, you are running steve not in the default (i.e. UTC) but some other timezone?

The date inputs are always assuming the browser OS timezone while the server expects UTC dates. It can't work properly if the date inputs are not translated to UTC, which is not the case currently.
Either the date inputs are documented to input UTC date (few work), either they are translated to UTC given the browser timezone, CSMS OS timezone and charging station configured timezone (a lot of work).

@jerome-benoit
Copy link
Author

jerome-benoit commented Jun 11, 2024

For now, I've commented out all @Future date validation in order to be able to input UTC dates in UTC+ timezone.

If it's considered as a reasonable solution for now, I can make a PR.

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

No branches or pull requests

2 participants