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