Please make sure the device is connected to Cloud and follow the steps below:
Check and set correct time zone.
After Cloud is connected, the device time will be synchronized to standard time you set.
Enter number into Handle DST.
Different countries could have different time difference for daylight saving.
Enter 1 if your device is 1 hour later after Daylight Saving
Note: It’s not allowed to enter negative number.
Click “confirm” to apply the setting.
If you need to change back to standard time，set “0” in text bar.
Hello, I don’t know if I understand correctly the operation of the “Handle DST” field.
In Spain, during winter time, we have an offset of UTC +01:00, and during summer time, we have an offset of UTC +02:00.
Could you tell me what values I should configure in the “Timezone” and “Handle DST” fields?
Thank you so much!
Hi, Thank you for asking.
Please configure UTC+01:00 in Timezone and 1 in HandleDST.
Setting HandleDST to 1 means the time changes to UTC+2:00 from UTC+01:00 during the summer time. When it’s winter time, you can configure it to 0.
I have configured as you indicated:
time zone = UTC +01:00
HandleDST = 1
Now, the dates are displayed correctly on the CrossChex Cloud website.
However, we are receiving the wrong dates via the CrossChex Cloud Webhooks. The “check_time” that we are receiving is “2023-06-21T18:31:11+00:00” but it should be “2023-06-21T17:31:11+00:00” that is to say “2023-06-21T19: 31:11+02:00”.
I have to say that the time on the device is displayed correctly in local time.
On the other hand, as you tell me, when winter time arrives, I will have to set HandleDST = 0. Is there a way to do this automatically? For example, if we could configure the timezone as CEST, instead of the offset, this would already imply a timezone of UTC +01:00 in winter and UTC +02:00 in summer, without having to change it manually.
I have noticed that the device had the timezone set to “GMT” and did not have DST set.
Therefore, in the device I have configured the timezone as GMT +01:00 and the DST with the “week” option:
- Modify: +1
- Start: March, Sunday, Last, 02:00
- End: October, Sunday, Last, 03:00
This seemed to be the solution to the problem, but now, the time of the device indicates one hour less and in the records that arrive by WebHook, the check_time should be “2023-06-23T17:31:11+00:00” but it arrives on value “2023-06-23T18:31:11+00:00”.
I checked with the R&D. He said the interface returns data without daylight saving time by default. If you’re in a country that applies DST, you have to process data according to your time.
Time zone = UTC +01:00
HandleDST = 1
The “check_time” that we are receiving is “2023-06-21T18:31:11+00:00”
The setting is correct. We suggest you subtract HandleDST from check_time.
The Webhook system sends a json with the check_time field in UTC time format, that is, without offset, and therefore it is also not affected by the local DST that I may have.
It is correct that the information is sent in UTC, because this way it does not have to be adapted to the local time of the recipient, and it is the recipient who, based on the UTC time, will have to transform it to local time.
So far so good.
The problem is that when I change the timezone setting in Crosschex Cloud, it affects the UTC time that I receive by Webhook, and this should not happen, since the UTC time should be the same regardless of the timezone that I set in Crosschex Cloud so that the data is viewed in local time (i.e. this should not affect device time)
Actually it designs this way. The time zone setting in Cloud needs to be related to UTC time and device time so that they can correspond, the report can be easily calculated and this can avoid time confusion.
We appreciate if you have any different ideas and you can share more opinions.