Skip to main content

The system flows are using the GMT time. But if we want a snapshot of the stock every day at 00:01 we run into a problem on switch over to the Daylight saving (DST) time period. 
In wintertime it’s 1 hr difference. And in Summertime (DST) we have a 2hr difference which will lead the snapshot of the stock is created at 23:00 hr. (If we put 01:00 in the IAM schedule) 

 

Does someone has a solution for this?

 

Would this maybe be possible to fix if you configure the Thinkwise service account, under which the Indicium is running, from UTC to Europe\Amsterdam ?


Hello ​@Edwin Saan,

I'm not sure if you have tried ​@C. Lousberg's suggestion yet, but it will not work. System flows are always scheduled in UTC time, which is GMT + 0. One of several reasons for this is actually to prevent problems with DST, because a much more common pattern is that some must happen exactly once every hour, and then on the switch to or from DST, twice a year, you would run into the situation that the schedule either skips an hour or runs twice in that hour.

If you want your system flow to always start at the same time relative to the local time, then I think your best option is to configure the schedule such that it runs on two consecutive hours and then use a Decision process action to determine based on the SYSUTCDATETIME() whether you are skipping that instance of the system flow or not.

If I understand you correctly, you want the system flow to always run at 00:01 local time, so this means that in UTC time it needs to run at 23:01 in winter time and 22:01 in summer time. So my suggestion would be to schedule the system flow for both of those times. Then, in the decision node I mentioned, you check the current UTC time and whether you're in summer time or winter time and based on that information you skip the first or  the second system flow. If your database server runs in the same local time, then it is quite easy to distinguish summer time from winter time, by simply checking the difference in hours SELECT DATEDIFF(HOUR, SYSUTCDATETIME(), GETDATE()) . If your database server is not guaranteed to run in the same local time, then you can still derive summer time and winter time from the knowledge that they always start at 01:00 UTC on the last Sunday of March and October respectively.

I asked an LLM to generate this for me, I have not validated it myself but it looks good.

CREATE FUNCTION dbo.IsNetherlandsInSummerTime()
RETURNS BIT
AS
BEGIN
DECLARE @CurrentUTC DATETIME = GETUTCDATE();
DECLARE @CurrentYear INT = YEAR(@CurrentUTC);

-- Get last Sunday of March at 01:00 UTC
DECLARE @March31 DATE = DATEFROMPARTS(@CurrentYear, 3, 31);
DECLARE @MarchLastSunday DATETIME =
DATEADD(HOUR, 1, DATEADD(DAY, -((DATEPART(WEEKDAY, @March31) + @@DATEFIRST - 1) % 7), CAST(@March31 AS DATETIME)));

-- Get last Sunday of October at 01:00 UTC
DECLARE @Oct31 DATE = DATEFROMPARTS(@CurrentYear, 10, 31);
DECLARE @OctLastSunday DATETIME =
DATEADD(HOUR, 1, DATEADD(DAY, -((DATEPART(WEEKDAY, @Oct31) + @@DATEFIRST - 1) % 7), CAST(@Oct31 AS DATETIME)));

-- If current UTC time is between March last Sunday at 1:00 and October last Sunday at 1:00, return 1 (DST)
IF @CurrentUTC >= @MarchLastSunday AND @CurrentUTC < @OctLastSunday
RETURN 1; -- Summer time
ELSE
RETURN 0; -- Winter time
END;

EDIT:

As I was submitting this reply I realized that there's a much simpler method, since you can just check the time zone offset. But I will leave the previous version of the function as well, they should both work.

CREATE FUNCTION dbo.IsNetherlandsInSummerTime()
RETURNS BIT
AS
BEGIN
DECLARE @NLTime DATETIMEOFFSET = SYSDATETIMEOFFSET() AT TIME ZONE 'UTC' AT TIME ZONE 'Central European Standard Time';

-- Offset +02:00 = Summer Time (DST), +01:00 = Winter Time
IF DATEPART(TZOFFSET, @NLTime) = 120
RETURN 1; -- Summer time
ELSE
RETURN 0; -- Winter time
END;

Or even like this:

SELECT is_currently_dst FROM sys.time_zone_info where name = 'Central Europe Standard Time'

I hope this helps.


Vincent, thanks for your reply. I already thought of a solution like this. I schedule the system flow just every hour. And in a first decision box I’ll check the hour of the current (server) datetime. If it’s 12 AM I can continue.

 


I can imagine other developers will run into this issue. So in the low-code mindset perhaps create an idea for this to be a setting on the process flow. You would have my vote. 


Reply