indicador mktime y tm_isdst

Tengo la siguiente duda sobre el uso del indicador tm_isdst en la estructura tm. Como por páginas man y googled resultados, entiendo que su valor se interpreta como sigueindicador mktime y tm_isdst

A. Un valor de 0 indica DST no es en efecto para el tiempo representado

B. Un valor de 1 indica DST es en efecto

C. Un valor de -1 hace que mktime verifique si DST está en efecto o no.

Este es el tercer punto que me confunde. Mi duda es cómo mktime puede determinar si el DST debe aplicarse o no con precisión.

Por ejemplo

My Time Zone = GMT + 3:00 
DST shifting = +1 Hour at 5:00 AM in January (to keep it simple) 
Current UTC time = "01/Jan/2012 00:00:00" 
UTC time in seconds time_t timetUTC = X seconds 
Hence my time is = "01/Jan/2012 03:00:00"

medida que pasa el tiempo, mis cambios de valor de tiempo de la siguiente manera

"01/Jan/2012 04:00:00"   (X + 1 * 60 * 60) 
"01/Jan/2012 05:00:00"   (X + 2 * 60 * 60) 
"01/Jan/2012 05:59:59"   (X + 2 * 60 * 60 + 59) 
"01/Jan/2012 05:00:00"   (X + 3 * 60 * 60) 
"01/Jan/2012 06:00:00"   (X + 4 * 60 * 60)

Según mi entendimiento

tm tmMyTime = localtime_r(X + 2 * 60 * 60) will set tmMyTime.tm_isdst to 0 
tm tmMyTime = localtime_r(X + 3 * 60 * 60) will set tmMyTime.tm_isdst to 1

De esta manera, a pesar de todos los demás componentes de tm structure son iguales en ambos casos, mktime (tmMyTime) puede devolver p valor de UTC de Roper, según el valor de tm_isdst.

Ahora, si configuro tmMyTime.tm_isdst = -1, ¿qué valor devolvería mktime? Leí acerca de la variable TZ, la base de datos de tiempo, etc. A pesar de todo, lógicamente, ¿cómo puede mktime() determinar si aplicar la corrección DST o no para esos valores tm que pueden aparecer dos veces?

No contamos con horario de verano en nuestra zona horaria. Por lo tanto, no estoy muy seguro de si mi comprensión es correcta. Por favor, corríjame si estoy equivocado. Su ayuda es muy apreciada.

Fuente

2012-05-10 mpathi

Descubrió que la hora local es ambigua. Es. –

En resumen: depende de la implementación.

mktime conoce las reglas de horario de verano comprobando la configuración regional.

Durante la mayor parte del año, mktime puede determinar si el horario de verano debe aplicarse para una hora local en particular. El problema es de hecho la hora "duplicada" cuando el horario de verano cambia hacia atrás (en su ejemplo 05:00:00 - 05:59:59). Para este rango de tiempo local, dado tm_isdst = -1, mktime no puede saber si DST está en efecto o no. Cuál de estos se elige, difiere de una implementación a otra. Con la versión GNU de mktime, se devuelve el UTC antes del cambio.

Fuente

2012-05-13 13:41:57 Pat

Gracias Pat. En el mejor de los casos, mktime solo puede hacer eso es lo que también sentí. Pero en ninguna parte (incluida la página del manual) había una descripción clara sobre el manejo de esta ambigua hora. Me confundí más al notar un reinicio deliberado de esta bandera en -1 en nuestro código base cada vez después de "tm = localtime_r (time_t)". Al menos en este caso, pensé que la bandera no debería tocarse. Además, creo que las implementaciones deben indicar claramente este comportamiento en la página de manual. O bien una función estándar debería dar siempre el resultado correcto o arrojar error al fallar o al menos mencionar desviaciones en la página man. – mpathi

Buena respuesta. El problema aquí es que si todo el usuario nos pasa es algo similar a una "struct tm", y nuestra única interfaz con la información de la zona horaria es Posix 'mktime()', tampoco podemos codificar el problema de forma portátil. O bien podemos forzar al usuario a especificar qué "3 de noviembre de 2013 a la 1:30:00 AM" nos están dando, o podemos simplemente configurar 'tm_isdst = -1' y esperar lo mejor. –

Creo que va a depender un poco de su plataforma. En Windows, al menos, la documentación de mktime() indica "La biblioteca de tiempo de ejecución C asume las reglas de Estados Unidos para implementar el cálculo del horario de verano", por lo que tiene una tabla de reglas en algún lugar donde puede determinar cuándo se inició DST/terminó en un año determinado.

Tienes suerte de no tener DST donde estés. En mi mundo, que es la adquisición y presentación de datos en tiempo real, ¡el horario de verano es una gran molestia!

Fuente

2012-05-10 18:37:25 pnswdv

Gracias por la respuesta. Sin embargo, todavía no está claro cómo mktime() puede hacer eso. Dado que dos valores UTC time_t pueden tener el mismo valor tm en la zona horaria local (excepto para is_dst), y si restablezco este indicador solo en -1, lógicamente la función mktime() no tiene ninguna pista sobre a cuál de los valores UTC debería convertirlo de nuevo a. – mpathi

tm_isdst En general, no se pueden resolver tiempos ambiguos. Esto se debe a que muchas zonas horarias tienen transiciones (una sola vez) sin saltar de dst a nodst, simplemente cambiando el desplazamiento y la abreviación de zona. Entonces las dos veces (antes y después de la transición) tienen el mismo tm_isdst. Algunas otras zonas cambian tm_isdst al cambiar el horario de verano/invierno pero no cambian las abreviaturas (Australia/Melbourne, por ejemplo).

Fuente

2013-12-19 11:26:36

Respuesta

Cuestiones relacionadas