¿Por qué AT TIME ZONE no es determinista?

SQL Server 2016 AT TIME ZONEparece no ser determinista. Sin embargo, no he podido encontrar documentación que lo declare oficialmente o que justifique el razonamiento detrás de esto.

¿Por qué es AT TIME ZONEno determinista?

Ejemplo que muestra no determinismo

Ejecutando:

CREATE TABLE Test (
    LegacyTimestamp DATETIME,
    Timestamp AS LegacyTimestamp AT TIME ZONE 'Eastern Standard Time' PERSISTED
);

Devuelve el siguiente error:

Msg 4936, Level 16, State 1, Line 1
Computed column 'Timestamp' in table 'Test' cannot be persisted because the column is non-deterministic.

sql-server sql-server-2016 timezone

— Ben Gribaudo
fuente

Tres palabras. El horario de verano.

— paparazzo

Bienvenido a la pesadilla conocida como tiempo. Casi desearía que fuera obligatorio cuando almacena la hora, también almacenó qué zona horaria también. Ahorraría mucho en medicamentos para el dolor de cabeza.

— Eric S

Acabo de crear un elemento de Microsoft Connect que solicita que se actualice la documentación para reflejar el no determinismo de 'AT TIME ZONE'.

— Ben Gribaudo

Respuestas:

AT TIME ZONE emplea cierta lógica para calcular el horario de verano. Los valores de desplazamiento de DST no son inmutables (están sujetos a cambios a través de actualizaciones de Windows ) y están contenidos externamente en el registro de Windows, por lo que la AT TIME ZONEfunción no puede ser determinista ya que depende de datos externos.

Del mismo modo, esta es la razón por la cual sys.time_zone_infoes una vista y no una tabla de referencia estática, debe calcularse en función de los valores del registro que tienen la información de zona horaria más actualizada.

— LowlyDBA
fuente

Pero, ¿no debería calcularse en referencia a la fecha que se está convirtiendo? Si no es determinista, es porque la regla de qué día comienza el horario de verano puede cambiar en el futuro, como sucedió en 2009.

— Random832

@ Random832 ¡Correcto! Me salteé algunos detalles para esto, lo actualicé para ser más claro.

— LowlyDBA

@ Random832, considere no solo fechas pasadas sino fechas futuras. Si se almacena una fecha futura en función de las reglas de cambio de hora que existen hoy en día, el valor se invalidará si las reglas cambian de vez en cuando,

— Dan Guzman

John: esta es una buena información, pero ¿no sería más preciso desde el punto de vista técnico reorganizar esto un poco para decir que la razón real de que no es determinista se debe simplemente a la dependencia externa de obtener la información del registro? Claro, por qué tiene que obtener la información de allí en lugar de estar codificado en el código de la aplicación (es decir, la causa raíz) se debe principalmente a la frecuencia con la que cambian las reglas de DST y al hecho de que se pueden introducir nuevas zonas horarias, pero eso es realmente secundario, ¿verdad? Pero independientemente del "por qué", cualquier dependencia externa debería hacer que cualquier función no sea determinista.

— Solomon Rutzky

¡Increíble! Para su información, encontré información bastante interesante aquí, en.wikipedia.org/wiki/Tz_database , que parece ser uno de los pocos documentos (al menos que pude encontrar hasta ahora) que indican que el horario de verano no es lo único. cambiar. Por lo que puedo decir al mirar el archivo C: \ Windows \ Globalization \ Time Zone \ timezones.xml , incluso las compensaciones básicas pueden cambiar con el tiempo, aunque con menos frecuencia desde 1970, supongo. +1 :-) (tuvo que volver a publicar esto ya que el enlace tenía un mal carácter)

— Solomon Rutzky

Agregué AT TIME ZONE a la lista no determinista en el tema Deterministic and Nondeterministic, y en el tema AT TIME ZONE, agregué: Dado que cierta información (como las reglas de zona horaria) se mantiene fuera de SQL Server y está sujeta a cambios ocasionales, la función AT TIME ZONE se clasifica como no determinista. Gracias por mencionar esto. Rick Byham, Libros en pantalla de SQL Server.

— Rick Byham no implica ninguna garantía
fuente

¡Esto debería ser un comentario en lugar de una respuesta!

— Kin Shah