question

Upvotes
3 3 3 3

Continous Screening date/time range issue related to time zones

Starting June 6th a client in Europe running our code has been having issues with SO returning an error that continuous screening is returning an invalid date range. The problem appears to be that the request is being built based on the current date/time where the client is (UTC+2), but the SO server is complaining that the request is asking for 2 hours more data than what SO has. The code is converting local time to London time so it is currently sending UTC+2 as the time. Note that prior to June 6th, everything worked and there were no time changes that I'm aware of.

Basically it looks like SO is expecting the actual current UTC time not the current local time converted to UTC (I believe the London time zone in the code is wrong) . Is that the case or is something else wrong?

world-checkscreeningscreening-api
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

· Write an Answer
Upvotes
3 3 3 3

Actually looking at this more, I'm fairly certain the code is wrong. The documentation says to send GMT time and the code is sending London time, which would be wrong during DST. The thing that is puzzling is that DST starts in March in Europe. This problem started in June.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.