Bug when subtracting dates between 12 AM - 1 AM

[Marielle]

I have flows that subtract two dates in order to determine the whether the current shift is A or B based on a repeating 14-day pattern.

However, if the time is between 12 AM - 1 AM, sometimes the dates do not subtract correctly.

I recreated the bug with a simplified script:

Code: Select all

start = getDate(2018,3,4);
end = getDate(2018,3,12);
days = (end - start)/86400000; 

Here "days" equals only 7 days, when it should be 8. I divide by 86400000 to convert from milliseconds to days, but this error happens even if I leave the value in milliseconds, minutes, or hours then convert to # of days in a calculator by hand. I usually use a specific date like the (2018,3,4) in the example for start and getDate() for end. The error happens both ways.

If I use getDate() and manually set the time on my device to 12:59 AM, immediately at 1 AM it shows the correct number of elapsed days. I have this bug on multiple devices: tablets and a phone.

Some dates don't have this bug. For example, using May instead of March: getDate(2018,5,4) and getDate(2018,5,12). Or using 2017 instead of 2018: getDate(2017,3,4) and getDate(2017,3,12).

I used this website for testing various combinations. It happens when the difference is 8 days, 99 days, and various others. I couldn't pinpoint a specific trigger.
https://www.timeanddate.com/date/durati ... i2=30&s2=0

If this is indeed a bug with Automagic, is there an alternate way of calculating the number of days between two dates I can use in the meantime?

[Desmanto]

"Mysterious thing, Time. Powerful, and when meddled with, dangerous."
J.K. Rowling

Can't help but to think about that quote.
==============================

After I saw your post, I immediately know it will work fine at my phone. And yes, I tried it and have no problem. This is not a bug. The culprit is the timezone, more specifically : The Daylight Saving Time. I am from equator, we don't have DST here, and I have no experience dealing with it either.

You probably live in country which enter the DST during the second sunday of March. I guess it is EDT (currently UTC-4), and later will switch back to EST (UTC-5). This year, the DST is switched on 11 March 2018, which is inside the range of your script date range calculation. Last year is on 12 March 2017. The DST switches at 02:00 AM, so it is outside of your script already, hence 2017 not affected.

This is a known problem when dealing with timezone and DST, it seems kinda painful to deal with. But I've never deal with it personally, never really looked into it.

The only way you can get a correct difference in days (or time) is to properly add back both time range to their timezone. Thus you get the real UTC+0 for both start and end, before starting to calculate the duration between them.

Let's use the dateformat with "z" pattern. When you use "{start,dateformat,z}", it will show the timezone of the {start}, in your case, probably it is EDT or EST. At mine it will be shown as GMT+07:00. When you use getDate(date, pattern) function to it, using the pattern "z", you will convert the timezone to miliseconds adjustment since epoch date, example at mine is -25200000. Divided it by 3600000 to get the hours, I got -7. However this is in reverse, so my UTC+7 will show up as -7 in this case. Need to invert it. So the full formula now is

Code: Select all

tzs = -getDate("{start,dateformat,z}", "z") / 3600000;

Now you script should become something like this

Code: Select all

start = getDate(2018,3,4);
end = getDate(2018,3,11);
tzs = -getDate("{start,dateformat,z}", "z")/3600000;
tze = -getDate("{end,dateformat,z}", "z")/3600000;
days = (addHours(end,tze) - addHours(start,tzs))/86400000;

I check with EDT timezone, DST currently on. The script above can calculate all different DST timezone properly.

[Marielle]

After I posted, I suspected it was daylight savings related because it was always off by one hour (2017 working fine did throw me off quite a bit!), but wasn't sure if there was a simple solution. So this helps a lot, thank you!