until option with relative values

[nikotaf]

I'm getting strange results with relative values. My tests are done in console in Chrome at http://keith-wood.name/countdownBasics.html. I'm pretty sure this is caused by the daylight saving hour, but I'm using relative values, so this shouldn't be the case.
The code I use:

$('#defaultCountdown').countdown('destroy').countdown({
	until:{relative values here},
	format:'odHMS'
}).countdown('pause');

I will only show the relative values and the result

Case 1:

'+0y +1o +1d +1h +1m +1s'

Result: (correct)

1month 1day 1hour 1min 1sec

Case 2:

+0y +2o +1d +1h +1m +1s

Result: (wrong)

2month 1day 0hour 1min 1sec

Case 3: with {timezone:+2} (my timezone)

+0y +1o +1d +1h +1m +1s

Result: (correct)

1month 1day 1hour 1min 1sec

Case 4: with {timezone:+1}

+0y +1o +1d +1h +1m +1s

Result: (wrong)

1month 1day 3hour 1min 1sec

Case 4: with {timezone:-1}

+0y +1o +1d +1h +1m +1s

Result: (wrong)

1month 1day 5hour 1min 1sec

I fully understand, that this is an issue of the daylight saving hour, but it should not be applied to relative values. Some facts need specific time to complete once started, and they don't care for daylight saving time. Why should I have extra or reduced time counted?

I would also like to add that some of the relative values, do not cross the daylight saving hour date.
Current date is September 14, and the said date is at October 29. Most of my tests use 1 month and a day.

Some other test I did with higher in-/decreased relative values, have shown me that, the combination of timezone and more than +1 month (+1o +15d +22h +32m +45s), always increases hour by 1 (gives 1month 15days 23hours 32min 45sec). Without timezone, and month between +2 to +6 (+4o +15d +22h +32m +45s), always decreases hour by 1 (gives 4months 15days 21hours 32min 45sec).

[kbwood]

Yes this is due to daylight savings coming in or going out. JavaScript doesn't handle date and times well, especially around these changes.

When you say you want a target time 1 month, 1 day, 1 hour in the future the plugin calculates that new date/time directly by adding to the current time. If that new value crosses a daylight saving boundary then the result is one hour more or less than expected when calculated as seconds difference since JS has automatically taken DS into effect. JS doesn't provide a way to query DS boundaries, so there's nothing the plugin can do to correct things.

Furthermore if you say you want a time 1 month, 1 day, 1 hour in the future across a DS boundary, do you mean the equivalent time as calculated above or the actual elapsed time? How is the plugin to know which?

[nikotaf]

In my tests, none of the testing values crosses the daylight saving hour date.

It would be nice to differentiate the calculation of relative times. Instead of adding them to current time, you could just pass to the plugin the actual seconds to the future. E.g.

+1d = 24*60*60*1000 (86400000)
+1h =    60*60*1000 ( 3600000)
+1m =       60*1000 (  600000)
+1s =          1000 (    1000)
------------------------------
           90601000 milis or 90601 sec

and then start counting.

In case of months, days should be calculated, (28,29,30,31)*24*60*60*1000.
In that case, even if daylight saving occurs, the time span is the same.

[munkeez-asa]

I found a workaround for this problem:

If you specify the until value as a number of seconds that crosses a daylight savings time event, then the resulting countdown time will be off by the DST offset.

If you specify the until value as a string containing the number of seconds that crosses a daylight savings time even, then the resulting countdown time will be correct. I've tried with and without the + sign and with and without the s (seconds) indicator at the end and the result is that it works.

I looked through the code a little bit and it seems there are two separate functions for setting until, one that handles numeric value and one that handles string values. For my usage the string version is correct.

I hope this helps someone who comes across this issue to fix their DST problems.

[munkeez-asa]

Correction to my previous post... this workaround only seems to work in the "Fall back" scenario. During the "Spring forward" DST event, even setting the until as a string value doesn't protect against the DST offset bug. This is really disappointing that this bug has been here so long with no attempt from the author to address it. I'm using this library for a time-sensitive game that relies heavily on countdown timers and it's really annoying to need to pause the game for 4 weekends every year due to this bug. I guess it's time to find a different library for countdowns.