Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

234
Views
Convierta la fecha y hora Utc en la fecha y hora local del usuario web

Tengo un sitio web .NET que captura un valor C# DateTime y lo almacena en la base de datos con valor UTC. Al mostrar ese valor de fecha y hora en la página web, lo que quiero es que el valor UTC de fecha y hora se convierta correctamente a la zona horaria local del usuario web. Por lo tanto, los usuarios de la web en diferentes zonas horarias verán el valor de fecha y hora mostrado con diferentes resultados de fecha y hora.

Tengo 2 enfoques siguientes. No sé cuál es la mejor y la correcta.

Enfoque 1: Deje que los códigos del lado del servidor de C# conviertan el valor UTC DateTime a la fecha y hora local mediante el método de la biblioteca .NET DateTime.ToLocalTime() y pase ese valor convertido al lado del cliente para que se muestre sin más códigos del lado del cliente.

Enfoque 2: no hago ninguna conversión de tiempo usando códigos del lado del servidor C#. En cambio, simplemente paso el valor de fecha y hora UTC al lado del cliente y usaré algunos códigos del lado del cliente (javaScript o alguna biblioteca JS) para hacer la conversión antes de mostrársela al usuario web.

Pregunta 1: ¿El enfoque 1 o el enfoque 2 es el mejor y el correcto?

Pregunta 2: El método DateTime.ToLocalTime() de la biblioteca .NET convertirá un valor de fecha y hora a la hora local del usuario web; la hora local del servidor web; ¿O el tiempo del sistema operativo de la computadora del usuario web?

Pregunta 3: ¿Cómo puedo probar mi página web con diferentes zonas horarias para ver si funciona el enfoque mejor/correcto?

Gracias por tu ayuda.

about 4 years ago · Juan Pablo Isaza
1 answers
Answer question

0

Sugiero que todas las fechas/horas se almacenen en UTC en el servidor y que, en su caso, realice la conversión de zona horaria del cliente web en el lado del cliente. Sugiero la biblioteca Moment para operaciones del lado del cliente. Si usa Moment, mire el método guess() para determinar la zona horaria actual del cliente.

Por cierto, es posible que desee determinar la zona horaria actual del cliente periódicamente en caso de que 1) el usuario esté en un dispositivo móvil y se mueva físicamente a otra zona horaria o, 2) la sesión del usuario dure lo suficiente como para pasar del horario de verano (DST) a la hora estándar (STD) o viceversa .

Ahora, dije "en su caso" porque, según su pregunta, no parece que tenga que preocuparse por calcular los intervalos de tiempo entre 2 fechas/horas. Si necesita hacer eso, también debe considerar la complicación de los cambios en una zona horaria de 3 fuentes:

  1. Cambio de STD a DST (y viceversa ) que ocurre dos veces al año en muchas zonas horarias.
  2. Cambios en el desplazamiento UTC de una zona horaria que a veces ocurre cuando un gobierno implementa un cambio.
  3. Cambios en la fecha/hora cuando una ubicación se convierte de STD a DST o viceversa .

Además, es posible que deba considerar la complicación de lidiar con la posibilidad de que una hora local corresponda a dos horas UTC. Esto puede suceder cuando la hora local de una ubicación se encuentra dentro de la hora anterior a la fecha/hora en que esa ubicación se convierte de DST a STD. Ese período de 1 hora se repite cuando se produce un 'retroceso' de DST a STD, por lo que debe resolver cuál de las 2 posibles horas UTC desea almacenar en su base de datos.

Si alguna de las complicaciones de la zona horaria anterior puede existir para usted, considere almacenar una ubicación junto con la fecha/hora, ya que este contexto es necesario para los cálculos de la zona horaria. La ubicación puede ser latitud/longitud, lo que necesitaría asignar a una zona horaria o podría mantenerlo simple y almacenar solo la zona horaria. Lat/lon a veces es más deseable ya que a veces los gobiernos deciden mover una ubicación a una nueva zona horaria (pero esto es bastante raro).

about 4 years ago · Juan Pablo Isaza Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!