After the topic created a month ago (Duplicate punches after one hour) we’ve followed the instructions given by Sarah_Anviz, setting the timezone as GMT+ 1 and settings the DST also to +1. (we are in Italy, so we normally are in GMT+1 but starting from the last week of march to october we are in +2 due to the gmt )
The problem is that the crosschexcloud APIS return an incorrect check time.
For instance, we punched a test record on 12.21 (so 10.21 gmt+00) and the checktime returned is 11:21 +00.
Which is of course incorrect since it should be 10.21 +00. This is causing huge problems with our clients and we hope you can help us solving that.
Hi @Technical_Anviz can you please check here?
Probably is something regarded to the Daylight Saving time
@l.stramenga if you are using WebHooks integration, you can add value " 1 " to the Handle DST function on CrossChex Cloud, that may solve the time discrepancy.
If you´re using only API directly, my colleague Sarah will check that for you and reply ASAP.
Thanks!
Hi Leonardo, as the post says we’ve already set the DST to be +1. It was suggested in the previous post I linked
1 Like
Hi @l.stramenga ,
We’ll check and get back to you ASAP.
1 Like
Hi @l.stramenga ,
I checked with our 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.
Ok, that’s clear, but as I said, then the checktime returned should be +1 (and not +0).
We punched at 12.21 having set Gmt+1 as timezone and Dst+1
The record returned has a checktime equals to 11.21 Gmt+00, which in our country, considering the timezone gmt +1, is equivalent to 12.21.
So if we add the DST the final result is 13.21, which is simply wrong.
So there are 2 cases:
- The checktime should return 11.21 +1, that is congruent with the cloud settings.
- The checktime already calculates the DST in gmt +00 time
Since the 2 is not the case, reading your answer it must be 1.
