Time zone preferences - Githubissues

chuck-h commented 5 years ago

I understand the benefits of running the mysql and central station software in UTC "under the hood", and I do not suggest changing that.

However it would be convenient for the UI to present time/date in a local timezone. (If this is already possible, I missed the documentation for it.)

This can be a more subtle problem than it first appears, as the user may be in a different time zone from the charging equipment, or may be traveling for that matter, and it is not always clear what the most useful or meaningful presentation is. (For example, see this discussion on a different energy-related application https://github.com/emoncms/emoncms/issues/1060 ).

Would be interested to hear other users' feelings on best practices. In my own use case, the network of CP is very small. However more broadly dispersed situations may benefit from a TZ field in the charge_box or address db tables.

One (perhaps stopgap) solution would be to implement a tool tip which pops up over any displayed time field. The tool tip would display all relevant zone times (e.g. equipment location TZ, administration TZ, browser TZ, UTC). That doesn't help much with time/date entry, however.

Comments? Also ref #88

goekay commented 5 years ago

However it would be convenient for the UI to present time/date in a local timezone.

i agree. it is not possible at the moment. this was bothering me for a long time, actually. my solution would be as follows:

leave the java backend and database in utc.
on the settings page we can have another input field for user time zone, that affects all information displayed on web pages. we can store this as a setting in db.
when any timestamp, datetime, etc. should be rendered, we convert it from utc to user time zone.
in web forms, the user can enter the date and time in her local time zone, and the backend can do the conversion to utc.

i think this is kind of the best practice of doing this thing. i can work on it, if i can find time, but cannot promise when.

elec-gio commented 4 years ago

With the current build (3.4.2) I have following to add:

Charging Profiles and GetCompositeSchedule:

First I set up a charging profile for "now" and sent it to the charger. Charger accepted and correctly processed the request (see logs excerpt below).

Right afterwards I requested the compositeSchedule for the (alleged) time frame but the charger answered with an empty schedule..

How could that be? After checking the logs, I could see why. The charger receives (correctly) the UTC time on startup, but the validFrom, validTo and startSchedule fields in the chargingSchedules are local time (CET ;-) but coded as UTC ("Zulu").

Then (after some search in the issues on this page) and your valid reason to stick to the timezone handling I first thought just to use the handy "now" button and correct the hour by hand with -1. But frankly this to much work. Then I just inserted the correct IANA time zone name (SteveConfiguration.java:46) which belongs to where my server is running and I'm located. After recompile it worked seamless.

(just have to keep in mind, when there is a new build...)

// SteVe Time: -> 2020-02-25T15:08:10.991Z (also time on charger), was sent with bootnotification.conf right before the setchargingprofile.req

// received message from steve:
{
    SetChargingProfileRequest: {
        connectorId: '3',
        csChargingProfiles: {
            stackLevel: '0',
            chargingProfileKind: 'Absolute',
            validTo: '2020-02-26T00:00:00.000Z',
            recurrencyKind: '',
            chargingProfilePurpose: 'TxDefaultProfile',
            transactionId: '',
            validFrom: '2020-02-25T16:06:00.000Z', //<- was inserted (and seen as it is) with "now" in dropdown
            chargingSchedule: [{
                    startSchedule: '2020-02-25T16:07:00.000Z', //<- was inserted with "now" in dropdown (and small correction to the minute)
                    chargingSchedulePeriod: [{
//                  [...]
                }
            ],
        }
    }
}

// after intenal conversion:
{
    'validTo': 1582675200, //-> 2020-02-26T00:00:00Z
    'priority': 0,
    'schedules': [{
            'duration': 300,
            'absStart': 1582646820, //-> 2020-02-26T16:07:00Z
            'periods': [{
//          [...]

rdc-Green commented 3 years ago

@elec-gio could you explain how you did this please:

Then I just inserted the correct IANA time zone name (SteveConfiguration.java:46)

'

goekay commented 3 years ago

@rdc-Green he probably changed the following setting to the time zone id of his local server.

https://github.com/RWTH-i5-IDSG/steve/blob/364ae967d0a7bafd7da8838a65a4d13dc9918dfd/src/main/java/de/rwth/idsg/steve/SteveConfiguration.java#L46

after changing this line, you need to recompile & package the project.

rdc-Green commented 3 years ago

Thanks for the swift response @goekay, do you know if I also need to change timezone in MySQL too, or will it just filter through

goekay commented 3 years ago

i am not sure, because there are many levels of time zone handling. it would be best to always keep both in sync.

goekay commented 3 years ago

more details about this for future visitors:

we are actually passing this config through as a parameter with the database connection:

https://github.com/RWTH-i5-IDSG/steve/blob/364ae967d0a7bafd7da8838a65a4d13dc9918dfd/src/main/java/de/rwth/idsg/steve/config/BeanConfiguration.java#L97

but still, being safe is better. time zones are hard. edge cases are many.

rdc-Green commented 3 years ago

i am not sure, because there are many levels of time zone handling. it would be best to always keep both in sync.

ok, i'll look at updating both. I'll report back if i'm successful!

elec-gio commented 3 years ago

@elec-gio could you explain how you did this please:

Then I just inserted the correct IANA time zone name (SteveConfiguration.java:46)

'

@rdc-Green he probably changed the following setting to the time zone id of his local server.

https://github.com/RWTH-i5-IDSG/steve/blob/364ae967d0a7bafd7da8838a65a4d13dc9918dfd/src/main/java/de/rwth/idsg/steve/SteveConfiguration.java#L46

after changing this line, you need to recompile & package the project.

@rdc-Green that's exactly how I did it. And for testing purposes I didn't run into troubles for my test set up. But I can say, that we (EVSE development) are working with SteVe (without "time-hack") for low-mid productive chargers (~200 charge points) and it works seamingless.

rdc-Green commented 3 years ago

Just to confirm we successfully updated the timezone in Steve using the method above. We also changed the timezone in the server, which MySQL uses.

rdc-Green commented 3 years ago

So i've noticed that the time in the SteVe log is correct, however it sends the incorrect time to the chargepoint whenever it sends a heartbeat:

 [INFO ] 2021-05-08 00:59:25,837 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=STR_0006, 
 sessionId=7ba491e1-c4ac-8dd1-5014-d492f409944f] Sending: [3,"4495",{"currentTime":"2021-05-08T00:59:25.820+01:00"}]

As you can see it sends current time +01:00. I believe the charge point then sends back the incorrect time

The charge point also sends the incorrect time when responding to a start transaction:

 [INFO ] 2021-05-08 09:27:33,059 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=STR_0006, 
 sessionId=7ba491e1-c4ac-8dd1-5014-d492f409944f] Sending: [3,"4505",{"transactionId":1930,"idTagInfo": 
 {"status":"Accepted","expiryDate":"2021-05-08T10:27:33.006+01:00"}}]

This is my charge session (the actual start time is 13:52):

The chargepoint is sending the right information during the transaction:

 [INFO ] 2021-05-08 13:55:12,439 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=STR_0006, 
 sessionId=7ba491e1-c4ac-8dd1-5014-d492f409944f] Received: [2,"4552","MeterValues", 
{"connectorId":1,"transactionId":1936,"meterValue":[{"timestamp":"2021-05-08T13:55:00Z","sampledValue": 
[{"value":"3912030.000","context":"Sample.Clock","measurand":"Energy.Active.Import.Register","location":"Outlet","unit":"Wh"}, 
{"value":"5.720","context":"Sample.Clock","measurand":"Power.Active.Import","location":"Outlet","unit":"W"}]}]}]

The time in the chargepoint is correct

Is there somewhere to change this config as well as Line 46? Thanks

goekay commented 3 years ago

So i've noticed that the time in the SteVe log is correct, however it sends the incorrect time to the chargepoint whenever it sends a heartbeat: ... As you can see it sends current time +01:00.

2021-05-08 00:59:25,837 and 2021-05-08T00:59:25.820+01:00 are not in contradiction to each other.

2021-05-08 00:59:25,837 expresses "this is my current time".

2021-05-08T00:59:25.820+01:00 expresses "this is my current time, which is +01:00 of UTC.

rdc-Green commented 3 years ago

But why is it expressing two different times? I'm sorry, but I don't understand the 1st line of your comment. Are they not two different times for the same transaction?

csamsel commented 3 years ago

No, one is annotated with the timezone in local time, one is in UTC.

rdc-Green commented 3 years ago

ok, that makes sense @csamsel.

Do you know why the time is showing as 14:52:04.000 + 01:00 when the actual time is 13:52 in the transaction overview screen?

csamsel commented 3 years ago

Well 13:52 UTC is 14:52 GMT+1 (+0100)

goekay commented 3 years ago

@rdc-Green you are misinterpreting some of the stuff and we are talking different topics in parallel in this thread.

1.

But why is it expressing two different times? I'm sorry, but I don't understand the 1st line of your comment. Are they not two different times for the same transaction?

the following log line

[INFO ] 2021-05-08 00:59:25,837 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=STR_0006, 
 sessionId=7ba491e1-c4ac-8dd1-5014-d492f409944f] Sending: [3,"4495",{"currentTime":"2021-05-08T00:59:25.820+01:00"}]

contains two times, this is true. because these two times are taken at different parts of the system, and it is okay to have a slight difference between them. the first time is from the logging subsystem. the second (the value of currentTime) is from the business logic of steve. this log line is not related to a transaction... at all. it has nothing to do with a transaction.

steve does not send the wrong time to the station.

2.

The charge point also sends the incorrect time when responding to a start transaction:

 [INFO ] 2021-05-08 09:27:33,059 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=STR_0006, 
 sessionId=7ba491e1-c4ac-8dd1-5014-d492f409944f] Sending: [3,"4505",{"transactionId":1930,"idTagInfo": 
 {"status":"Accepted","expiryDate":"2021-05-08T10:27:33.006+01:00"}}]

this message is not from a charge point. this is what steve sends as a response to a charge point.

the expiryDate here must confuse you. it is not the current time. by default, we let the validity of an rfid tag expire after 1 hour in the station, such that the station MUST ask steve about its current status again. therefore, expiryDate (10:27) = current time (09:27) plus 1 hour. you see +01:00 at the end because this is your time zone.

3.

The chargepoint is sending the right information during the transaction:

 [INFO ] 2021-05-08 13:55:12,439 de.rwth.idsg.steve.ocpp.ws.WebSocketLogger - [chargeBoxId=STR_0006, 
 sessionId=7ba491e1-c4ac-8dd1-5014-d492f409944f] Received: [2,"4552","MeterValues", 
{"connectorId":1,"transactionId":1936,"meterValue":[{"timestamp":"2021-05-08T13:55:00Z","sampledValue": 
[{"value":"3912030.000","context":"Sample.Clock","measurand":"Energy.Active.Import.Register","location":"Outlet","unit":"Wh"}, 
{"value":"5.720","context":"Sample.Clock","measurand":"Power.Active.Import","location":"Outlet","unit":"W"}]}]}]

i dont think the station is sending the right time. the meter value claims to be taken at 2021-05-08T13:55:00Z which is exactly the LOCAL time of the logging subsystem 2021-05-08 13:55:12,439 (disregard the seconds and milliseconds. they are not important for this discussion). and we know from before, that you are actually in +01:00.

a point in time with time zone +01:00 cannot be the same as UTC (which is +00:00).

my assumption is that your charging station cannot handle time zones well. this is why we are suggesting to leave everything in UTC (+00:00).

goekay commented 3 years ago

4.

my commentary about the point 3 would also explain your confusion that the actual start time is 13:52 but the values you see in steve are from 14:52 and later. i assume the following:

the station sends a transaction start message with 2021-05-08T13:52:00Z (actually meaning 13:52 local time in your time zone). but Z at the end signals UTC and hence +00:00
steve will interpret this time as 2021-05-08T14:52:00+01:00 because 2021-05-08T14:52:00+01:00 = 2021-05-08T13:52:00Z
you see on the web pages of steve the records starting with 14:52 and are rightfully confused.

rdc-Green commented 3 years ago

@goekay that makes sense, thank you for explaining it so clearly. I will discuss with the charge point manufacturer. I will update the thread if I can get it to work.

goekay commented 3 years ago

if the charging really and actually started at 13:52 in your local time, the station should have used one of the following formats to express it:

2021-05-08T13:52:00+01:00
2021-05-08T12:52:00+00:00
2021-05-08T12:52:00Z
2021-05-08T13:52:00 (this is very dangerous because it does not contain any time zone offset information. steve will interpret this as being in the currently configured time zone of steve. however, as long as steve and stations are in the same time zone, you should be fine)

all of these possibilities express the same point in time in different formats.

rdc-Green commented 3 years ago

I have been doing some more testing with one of my charge points with the following results:

Set the time in the charge point to UTC

Send a boot notification - charge point time changes to UTC + 01:00
Send a heartbeart - charge point time changes to UTC + 01:00
Start a remote transaction - time stays the same
Send a trigger message during a remote transation - time changes to UTC + 01:00

In each of these cases the charge point is behaving as @goekay explains above whereby it sends a response back with the current time but with a 'Z', which the station then interprets as an hour ahead.

OCPP says that it is recommended for the charge point to use this time. Is this a decision for the charge point?

goekay commented 3 years ago

... which the station then interprets as an hour ahead.

i hope you meant steve and this was a typo.

OCPP says that it is recommended for the charge point to use this time. Is this a decision for the charge point?

ocpp suggests to use utc for all parties of the communication.

Set the time in the charge point to UTC

this is interesting. so, the station changes its time later as a reaction to the time in the responses from steve. therefore, i can imagine if the backend (steve) was in utc, these problems would not occur.

rdc-Green commented 3 years ago

... which the station then interprets as an hour ahead.

i hope you meant steve and this was i typo.

Yes, this was a typo, I meant steve

this is interesting. so, the station changes its time later as a reaction to the time in the responses from steve. therefore, i can imagine if the backend (steve) was in utc, these problems would not occur.

This is correct. the charge point sets the time, but still uses UTC format 'Z', which steve then interprets as an hour ahead. If I set the time to UTC in steve, then when a user schedules a charge it will be the incorrect time. Also all my reporting will be in UTC rather than UTC + 01:00 (BST)

goekay commented 3 years ago

If I set the time to UTC in steve, then when a user schedules a charge it will be the incorrect time.

true, currently the user has to do the mental arithmetics to convert the local time into utc, and enter this time in the forms.

Also all my reporting will be in UTC rather than UTC + 01:00 (BST).

yes... you tried to solve the problem by changing the operation which the station did not like. the solution would be to leave all the reports and timestamps as they are, and render them on the webpages with the correct offset that you can configure.

and hence the reason for this issue existing.

rdc-Green commented 3 years ago

as you say @goekay time zones are hard!

My preference would be for the charge point to have the option to select date format in UTC or 'no time zone offset' or the charge point doesn't update the local time based on the trigger message from steve

I don't understand how this can work with charge points across multiple time zones. Must be lots of rendering in the background and mental arithmetic for users.

goekay commented 3 years ago

My preference would be for the charge point to have the option to select date format in UTC or 'no time zone offset' or the charge point doesn't update the local time based on the trigger message from steve

steve uses a time library that implements https://en.wikipedia.org/wiki/ISO_8601. this standard covers everything regarding expressing points in times in various zones. if the stations did and would implement timezones and offsets correctly, you could use any timeZoneId in steve and everything would be fine.

rdc-Green commented 3 years ago

Yep, so its down to the station to implement the correct time for that location. I would have expected this to be resolved by now.

steve-community / steve

Time zone preferences #96

1.

2.

3.

4.