Así que tengo una aplicación de front-end construida con React y un back-end con .Net (C#). Tengo este problema de conversión de tiempo con 1 día de retraso.
Entonces, en mi interfaz, la fecha es correcta, en formato de hora local, y cuando la API (backend, C #) recibe los datos, convierte la fecha en UTC, lo que la retrasa 1 día.
cuando trato de obtener la diferencia de fecha local con la fecha UTC, el resultado es 0 usando el momento. Quiero mantener la fecha aunque esté en UTC.
Sugeriría usar las horas UTC para comunicar las fechas desde el frontend hasta el backend. No son ambiguos y no dependerán de la zona horaria en la que se encuentre el usuario.
Puede usar la hora de Unix , la cantidad de segundos/milisegundos desde el 1 de enero de 1970 a las 00:00 UTC, por ejemplo, 1635494392 o ISO 8601 , una codificación de cadena bien definida de fecha y hora, por ejemplo, 2021-10-29T08:27:22Z .
Recomiendo usar fechas ISO 8601 ya que son mucho más fáciles de observar que las fechas de Unix. También son compatibles con los objetos de fecha JS nativos y todas las bibliotecas de hora/fecha.
Si envía una fecha como 2021-10-29T08:27:22Z al backend, no será necesario convertirla a UTC y no existe ambigüedad.
Del mismo modo, cuando el frontend recibe una fecha del backend, el uso de una fecha ISO UTC significará que la fecha se analizará y entenderá sin ambigüedades.
También es fácil de convertir a la hora local, usando Date.toLocaleString() por ejemplo. Esto se mostrará en la zona horaria local del usuario de forma predeterminada, pero puede mostrarse en cualquier zona horaria usando el argumento { timeZone: 'xxx' }.
Por ejemplo:
const timestampFromBackend = '2021-10-29T08:27:22Z'; const dateFromBackend = new Date(timestampFromBackend); console.log('Date from backend (UTC):', dateFromBackend.toLocaleString([], { timeZone: 'UTC'})); console.log('Date from backend (local):', dateFromBackend.toLocaleString()); // We can display in any timezone if we wish console.log('Date from backend (Pacific Time):', dateFromBackend.toLocaleString([], { timeZone: 'America/Los_Angeles'})); .as-console-wrapper { max-height: 100% !important; top: 0; }Del mismo modo, siempre podemos convertir una fecha de interfaz en una fecha ISO UTC, usando Date.toISOString():
const frontEndDate = new Date(); const dateToBackend = frontEndDate.toISOString(); console.log('frontEndDate:', frontEndDate.toString() ); console.log('ISO string to send to backend:',dateToBackend); .as-console-wrapper { max-height: 100% !important; top: 0; }Una solución muy simple para eso es crear un objeto de fecha en la interfaz antes de enviar la solicitud, como:
var dt = new Date();y enviar eso al servidor. En el servidor, también puede medir la fecha en UTC, calcular la diferencia de los dos, redondearlo al valor de zona horaria válido más cercano posible (tenga cuidado con algunas zonas horarias, como Afganistán, si no recuerdo mal, tienen un desplazamiento de horas no completas, creo que está a unas 3 horas y 30 minutos de UTC) y agregue esa compensación a las fechas que se enviaron.
Entonces, además de los tiempos reales que su interfaz envía al servidor, mida el tiempo real y envíe eso también y en el servidor vea su distancia desde UTC.
Esto todavía no es 100% exacto, porque si algunas fechas son distantes del momento del envío de la solicitud y también están involucradas las compensaciones de DS (horario de verano), entonces es posible que se pierda una hora en algunos casos.
Si esta inexactitud es preocupante, entonces debemos agregar alguna complicación a la solución, es decir, en ese caso, es posible que deba obtener la ubicación del usuario en la interfaz. Tenga en cuenta que no tienen que permitir eso, por lo que esto podría ser inaccesible. Sin embargo, si conoce su ubicación, también conocerá su zona horaria. Y usando su zona horaria, puede convertir con precisión cualquier fecha de esa zona horaria a UTC .