CheckTime error with crosschexcloud API

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.
immagine

Hi @Sarah_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:

  1. The checktime should return 11.21 +1, that is congruent with the cloud settings.
  2. The checktime already calculates the DST in gmt +00 time

Since the 2 is not the case, reading your answer it must be 1.