Javascript обратный отсчет и проблемы с часовым поясом и летним временем

Question

У нашей команды большие проблемы с обратным отсчетом JQuery, и нам действительно нужна помощь.

Первоначально у нас был некоторый код ScriptSharp, который делает это

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");

Мы заметили, что для отсчета используются часы клиента. Таким образом, если клиент решит изменить свое время на 5 часов вперед, то обратный отсчет будет 5 часов.

Чтобы исправить это, мы ввели еще немного кода

По мнению:

   $(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;
        }
});

В контроллере

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;
        }

Этот код гарантирует, что независимо от того, что пользователь устанавливает свои часы на таймер обратного отсчета, будет периодически синхронизироваться со временем сервера. Задача решена.

Единственная проблема заключается в том, что у нас возникли другие проблемы.

Проблема заключается в том, что когда пользователи находятся в разных часовых поясах, обратные отсчеты этих пользователей различаются в зависимости от смещения часового пояса, которое имеет их часовой пояс. Мы попытались изменить всевозможные параметры и все еще имеем проблемы. Что еще хуже, если мой временной интервал колеблется от даты, когда применяется летнее время, то снова все идет наперекосяк, как для тех, кто находится в одном часовом поясе, так и в разных. Мы экспериментировали с другим кодом и параметрами, поэтому вышеизложенное - это то, что я сделал, и отличается от того, что пытались мои уважаемые коллеги. То, что я спрашиваю, конечно, кто-то где-то там, должно быть, имел требование

1. Напишите обратный отсчет, который не зависит от времени клиента и основан на времени сервера.
2. Показывает одинаковое количество дней, часов, минут, секунд, независимо от того, в каком часовом поясе находится пользователь
3. Показывает то же количество дней, часов, минут и секунд, оставшихся для пользователя, чье время изменится за этот период из-за перехода на летнее время, для пользователя, чье время не изменится за этот период из-за перехода на летнее время
4. Показывает фактическое количество дней, часов, минут и секунд, оставшихся для пользователя, чье время изменится в этот период из-за летнего времени.

Конечно, мы не можем быть единственными людьми, которые когда-либо сталкивались с этой проблемой. Это не может быть так сложно. Кто-нибудь знает решение?

Спасибо,

Сэчин

Answer 1

Лично я не имел дело с теми же сценариями, но появление всплывающего окна "Дата, проблемы с часовым поясом и т. Д." Автоматически вызывает мысли о некоторых потенциальных проблемах, связанных с использованием локальных объектов даты, а не объектов даты UTC.

IMO, все просто лучше, если все вычисления, сериализация дат работает только в пространстве UTC, и, наконец, когда дело доходит до представления даты от пользователя, она конвертируется в местный или соответствующий часовой пояс в зависимости от сценария. С другой стороны, пользователь вводит локальную или некоторую относительную запись часового пояса и сразу же преобразуется в UTC как внутреннее представление. Это позволяет избежать всевозможных путаниц в разных слоях / уровнях приложения.

Это не совсем решение вашей конкретной проблемы, но, возможно, что-то, что следует учитывать, может привести к одной.