Javascript countdown and timezone and daylight saving time issues

Question

Our team are having big issues with the JQuery countdown and we really need some help.

Initially, we had some ScriptSharp code that does this

JQueryCountdownOptions opts = new JQueryCountdownOptions();
opts.Layout = "<ul class=\"group\"> <li>{dn} <span>{dl}</span></li> <li>{hn} <span>{hl}</span></li> <li>{mn} <span>{ml}</span></li> <li>{sn} <span>{sl}</span></li> </ul>";
opts.Until = Number.ParseInt(timeLeft);

jQuery.Select("#countdownclock").Plugin<JQueryCountdown>().Countdown(opts);
jQuery.Select("#countdownclock").Show();
jQuery.Select("#bidBox").RemoveAttr("disabled");

What we noticed is that this uses the client's clock to countdown from. So, if the client decided to change his time to 5 hours ahead then the countdown would be 5 hours off.

To fix this we introduced some more code

In the view:

   $(function () {

        var expires = new Date(@year, @month, @day, @hours, @minutes, @seconds);
        $('#clockDiv').countdown({ until: expires, timeZone: null, serverSync: serverTime, onTick: serverTime, tickInterval: 60 });

        function serverTime() {
            var time = null;
            $.ajax({ url: '/Auction/SyncServerTime',
                async: false, dataType: 'json',
                success: function (result) {
                    time = new Date(result.serverTime);
                }, error: function (http, message, exc) {
                    time = new Date();
                }
            });
            return time;
        }
});

In the controller

public JsonResult SyncServerTime()
        {
            var result = new JsonResult
            {
                Data = new
                {
                    serverTime = DateTime.Now.ToString("MMM dd, yyyy HH:mm:ss zz")
                },
                JsonRequestBehavior = JsonRequestBehavior.AllowGet
            };
            return result;
        }

This code ensures that no matter what the user sets his clock to the countdown timer will periodically sync to the server's time. Problem solved.

The only issue is that we have come up with other issues.

The problem is that when users are in different timezones then the countdowns of those users are different depending on the timezone offset that their timezone has. We have tried changing all sorts of parameters and still are having issues. To make matters worse if my timespan straddles a date when daylight saving time is applied then things go awry again, both for those in the same timezone and those in different ones. We have experimented with different code and parameters so the above is just what I did and is different from what my esteemed colleagues tried. What I am asking is surely, someone somewhere out there must have had a requirement to

1. Write a countdown that is independent of client time and based on server time.
2. Shows the same number of days, hours, minutes, seconds remaining no matter what timezone a user is in
3. Shows the same number of days, hours, minutes, seconds remaining for a user whose time will change in this period because of DST to user whose time will not change in this period because of DST
4. Shows the actual number of days, hours, minutes and seconds remaining for a user whose time will change in this period because of DST.

We cannot be the only people who have ever had this issue, surely. It cannot be this hard. Does anyone know a solution?

Thanks,

Sachin

Answer 1

I haven't dealt with the same scenarios personally, but seeing Date, timezone issues etc. pop up automatically triggers thoughts about some potential issues stemming from the use of local date objects as opposed to UTC date objects.

IMO, things are simply better off if all computation, serialization of dates only worked in the UTC space, and finally when it comes to present a date from a user, it is converted to local or appropriate time zone depending on the scenario. On the flip-side, the user enters local or some time zone relative entry, and immediately that is converted to UTC as the internal representation. This avoids all sorts of confusion across different layers/tiers of the app.

Its not really a solution to your specific problem, but perhaps something to consider that could lead to one.