Cuenta regresiva de JavaScript y TimeZone y Tiempo de ahorro de día.

Question

Nuestro equipo está teniendo grandes problemas con la cuenta regresiva de JQuery y realmente necesitamos ayuda.

Inicialmente, tuvimos un código Scriptsharp que hace esto

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

Lo que notamos es que esto usa el reloj del cliente para la cuenta regresiva de. Por lo tanto, si el cliente decidió cambiar su tiempo a 5 horas adelante, la cuenta regresiva tendría 5 horas de descanso.

Para solucionar esto, presentamos más códigos

en la vista:

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

en el controlador

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

Este código asegura que no importa lo que el usuario establezca su reloj en el temporizador de cuenta regresiva se sincronizará periódicamente hasta el momento del servidor. Problema resuelto.

El único problema es que hemos encontrado otros problemas.

El problema es que cuando los usuarios están en diferentes tiempos de tiempo, las cuentas de cuenta caídas de esos usuarios son diferentes dependiendo de la compensación de la zona horaria que tiene su timzone. Hemos intentado cambiar todo tipo de parámetros y aún estamos teniendo problemas. Para empeorar las cosas si mi Timespan se extiende a salvo una fecha en que se aplica el tiempo de ahorro de la luz del día, las cosas vuelven a ir de nuevo, tanto para aquellos en la misma zona horaria como para los diferentes. Hemos experimentado con diferentes códigos y parámetros, por lo que lo anterior es justo lo que hice y es diferente de lo que intentaron mis estimados colegas. Lo que estoy preguntando es seguramente, alguien en algún lugar, debe haber tenido un requisito para

1. Escriba una cuenta regresiva que sea independiente del tiempo del cliente y se basa en la hora del servidor.
2. muestra el mismo número de días, horas, minutos, segundos que quedan sin importar lo que Timebone un usuario esté en
3. muestra el mismo número de días, horas, minutos, segundos que quedan para un usuario cuyo tiempo cambiará en este período debido a DST a usuario, cuyo tiempo no cambiará en este período debido a DST
4. muestra el real número de días, horas, minutos y segundos que permanecen para un usuario cuyo tiempo cambiará en este período debido a DST.

No podemos ser las únicas personas que han tenido este problema, seguramente. No puede ser esto duro. ¿Alguien sabe una solución?

gracias,

SACHIN

Answer 1

No he tratado con los mismos escenarios personalmente, pero ver la fecha, las cuestiones de TimeZone, etc. La ventana emergente activa automáticamente los pensamientos sobre algunos problemas potenciales derivados del uso de los objetos de la fecha local en lugar de los objetos de la fecha UTC.

IMO, las cosas están simplemente mejor si todos los cálculos, la serialización de las fechas solo funcionó en el espacio UTC, y finalmente, cuando se trata de presentar una fecha de un usuario, se convierte en zona horaria local o apropiada, dependiendo del escenario..En el lado del volteador, el usuario ingresa a la entrada relativa local o de una zona horaria, e inmediatamente que se convierte en UTC como la representación interna.Esto evita todo tipo de confusión en diferentes capas / niveles de la aplicación.

no es realmente una solución a su problema específico, pero quizás algo de considere que podría llevar a uno.