14 Pregunta: DateTime2 vs DateTime en SQL Server

pregunta creada en Mon, Mar 20, 2017 12:00 AM

Cual:

¿ es la forma recomendada para almacenar la fecha y la hora en SQL Server 2008+?

Soy consciente de las diferencias en la precisión (y probablemente en el espacio de almacenamiento), pero, por el momento, las ignoro. ¿Existe un documento de mejores prácticas sobre cuándo usar qué, o quizás deberíamos usar datetime2 solamente?

    
690
14 Respuestas                              14                         

La documentación de MSDN para datetime recomienda usar datetime2 . Aquí está su recomendación:

  

Utilice el time, date, datetime2 y    datetimeoffset tipos de datos para nuevos   trabajo. Estos tipos se alinean con el SQL   Estándar. Son más portátiles.    time, datetime2 y datetimeoffset   Proporcionar más segundos de precisión.    datetimeoffset proporciona zona horaria   Soporte para implementado globalmente.   aplicaciones.

datetime2 tiene un intervalo de fechas más amplio, una mayor precisión fraccional predeterminada y una precisión opcional especificada por el usuario. También, dependiendo de la precisión especificada por el usuario, puede usar menos almacenamiento.

    
578
2018-07-13 19: 20: 56Z
  1. mientras aumenta la precisión con datetime2, algunos clientes no admiten date, time o datetime2 y lo obligan a convertir a una cadena literal. Si le preocupa más la compatibilidad que la precisión, use datetime
    2014-06-25 20: 49: 56Z
  2. Otra opción es usar una vista indizada con la columna convertida como fecha y hora por compatibilidad. Sin embargo, deberías poder apuntar la aplicación a la vista.
    2017-05-08 16: 39: 22Z
  3. El soporte de zona horaria con DATETIMEOFFSET es un nombre inapropiado. Solo almacena un desplazamiento UTC para un instante específico en el tiempo, no una zona horaria.
    2017-06-01 12: 51: 42Z
  4. @ Porad: ¿Cuál es exactamente el beneficio en la práctica de ser "" más portátil "debido a ser" SQL Standard "? Eso es además de hacer que escriba mucho más código que es significativamente menos legible /mantenible para un "puerto" a otro RDBMS que es probable que nunca ocurra durante la vida útil de ese código. Aparte de las herramientas y los controladores de SQL Server provistos por Microsoft, ¿hay alguna aplicación que realmente dependa ¿Las representaciones específicas de nivel de bits del tipo DateTime2 (o cualquier otro tipo de servidor SQL para esa materia)? Consulte los Contras en mi 7/10/17 Responda a continuación para saber por qué lo pregunto.
    2017-07-10 23: 27: 49Z
  5. @ Adam Porad: Además, es probable que todos esos beneficios sean innecesarios (fuera de las aplicaciones de ingeniería o científicas) y, por lo tanto, no valgan la pena perderlos, mucho más probablemente: la capacidad mucho más fácil (incluso teniendo en cuenta las soluciones provisionales) para convertir implícitamente /explícitamente a un valor numérico de punto flotante (# de días, incl. aplic., días fraccionarios desde el mínimo de fecha y hora) para adiciones, restas, mínimos, máximos y promedios. Consulte los Contras en mi respuesta del 7/10/17 a continuación para obtener detalles.
    2017-08-10 23: 59: 28Z

DATETIME2 tiene un rango de fechas de "0001/01/01" a "9999/12/31", mientras que el tipo DATETIME solo admite el año 1753-9999.

Además, si lo necesita, DATETIME2 puede ser más preciso en términos dehora; DATETIME está limitado a 3 1/3 milisegundos, mientras que el DATETIME2 puede tener una precisión de hasta 100 ns.

Ambos tipos se asignan a System.DateTime en .NET, no hay diferencia.

Si tiene la opción, recomendaría usar DATETIME2 siempre que sea posible. No veo ningún beneficio al usar DATETIME (excepto por la compatibilidad con versiones anteriores): tendrá menos problemas (con fechas fuera de alcance y problemas como ese).

Plus: si solo necesita la fecha (sin la parte de la hora), use DATE - ¡es tan buena como la DATETIME2 y también le ahorra espacio! :-) Lo mismo ocurre con el tiempo solamente - use TIME. ¡Para eso están estos tipos!

    
465
2016-01-06 08: 25: 33Z
  1. Tenga cuidado al agregar un valor DateTime de .NET como parámetro a un SqlCommand, porque le gusta asumir que es el tipo de fecha y hora anterior, y obtendrá un error si intenta escribir un valor de DateTime que está fuera de ese rango de 1753-9999 años a menos que especifique explícitamente el tipo como System.Data.SqlDbType.DateTime2 para el parámetro SqlParameter. De todos modos, datetime2 es genial, porque puede almacenar cualquier valor que se pueda almacenar en el tipo de fecha y hora .NET.
    2010-10-26 18: 16: 33Z
  2. @ marc_s - ¿No es eso para lo que es nulo?
    2011-01-17 17: 15: 42Z
  3. @ JohnFx: intente establecer una estructura .NET DateTime en NULL .....
    2011-01-17 17: 40: 29Z
  4. @ JohnFX - un poco tarde aquí - pero no establecería un datetime en nulo. usaría Nullable < datetime > o datetime? que maneja nulo simplemente bien - y en la asignación a un proc simplemente haría param.value = someDateTime ?? DBValue.Null Es desafortunado que estemos atascados con un tipo de datos con un número detrás, simplemente parece tan 'genérico':)
    2011-06-01 18: 25: 20Z
  5. Lol, solo traté de promocionar mi propio comentario (arriba), antes de darme cuenta de que era mi propio comentario (realizado hace más de un año). Todavía estoy tratando con la decisión estúpida de diseño de .NET framework para TRUNCAR todos los valores de DateTime de forma predeterminada cuando se pasa como SqlParameters a menos que se establezca explícitamente en el SqlDbType.DateTime2 más preciso. Tanto para inferir automáticamente el tipo correcto. Realmente, deberían haber hecho el cambio transparente, reemplazando la implementación menos precisa, menos eficiente, de rango limitado, y conservando el nombre original del tipo "fecha y hora". Consulte también stackoverflow.com/q/8421332/88409
    2011-12-08 18: 25: 27Z

datetime2 gana en la mayoría de los aspectos, excepto (Compatibilidad con aplicaciones antiguas)

  1. mayor rango de valores
  2. mejor Precisión
  3. menor espacio de almacenamiento (si se especifica la precisión opcional especificada por el usuario)

SQL Los tipos de datos de fecha y hora se comparan - datetime, datetime2, date, TIME

tenga en cuenta los siguientes puntos

  • sintaxis
    • datetime2 [(precisión fraccional de segundos = > Mire debajo del tamaño de almacenamiento)]
  • precisión, escala
    • 0 a 7 dígitos, con una precisión de 100 ns.
    • La precisión predeterminada es de 7 dígitos.
  • Tamaño de almacenamiento
    • 6 bytes para precisión inferior a 3;
    • 7 bytes para precisión 3 y 4.
    • Todas las demás precisiones requieren 8 bytes .
  • DateTime2 (3) tiene el mismo número de dígitos que DateTime pero utiliza 7 bytes de almacenamiento en lugar de 8 bytes ( SQLHINTS- DateTime Vs DateTime2 )
  • Encuentre más información en datetime2 (artículo MSDN de Transact-SQL)

fuente de imagen: Kit de capacitación autodidacta de MCTS (examen 70-432): Microsoft® SQL Server® 2008 - Implementación y mantenimiento Capter 3: Tablas - > Lección 1: Crear tablas - > página 66

    
187
2017-10-18 21: 14: 10Z
  1. Gracias por mostrar que las estadísticas de +1, datetime2 es increíble (Ganador)
    2016-03-25 11: 54: 12Z
  2. @ Iman Abidi: De acuerdo con el comentario de Oskar Berggren del 10 de septiembre de 2014 a las 3:51 pm en el artículo "SQLHINTS- DateTime Vs DateTime2" al que hizo referencia: "datetime2 ( 3) NO es lo mismo que datetime. Tendrán el mismo número de dígitos, pero la precisión de datetime es de 3.33 ms, mientras que la precisión de datetime2 (3) es de 1 ms. "
    2017-07-10 23: 41: 19Z
  3. @ PankajParkar: Woah, no tan rápido. Es posible que desee consultar la sección Contras de mi respuesta del 7/10/17 a continuación.
    2017-07-10 23: 46: 15Z
  4. ¿Cómo utiliza datetime2 menos espacio de almacenamiento que datetime y, sin embargo, ofrece un mayor rango y mayor precisión?
    2019-03-27 09: 28: 21Z

Coincido con @marc_s y @Adam_Poward - DateTime2 es el método preferido para avanzar. Tiene un rango de fechas más amplio, mayor precisión y utiliza almacenamiento igual o menor (según la precisión).

Sin embargo, algo se perdió en la discusión ...
@Marc_s estados: Both types map to System.DateTime in .NET - no difference there. Esto es correcto, sin embargo, lo inverso no es cierto ... y es importante cuando se realizan búsquedas en el intervalo de fechas (por ejemplo, "Búscame todos los registros modificados el 5/5/2010").

La versión de .NET de Datetime tiene un rango y precisión similares a los de DateTime2. Al asignar un .net Datetime al antiguo SQL DateTime, se produce un redondeo implícito . El antiguo SQL DateTime tiene una precisión de 3 milisegundos. Esto significa que 11:59:59.997 es lo más cerca que puede llegar al final del día. Cualquier cosa superior se redondea al día siguiente.

Prueba esto:

 
declare @d1 datetime   = '5/5/2010 23:59:59.999'
declare @d2 datetime2  = '5/5/2010 23:59:59.999'
declare @d3 datetime   = '5/5/2010 23:59:59.997'
select @d1 as 'IAmMay6BecauseOfRounding', @d2 'May5', @d3 'StillMay5Because2msEarlier'

Evitar este redondeo implícito es una razón importante para pasar a DateTime2. El redondeo implícito de fechas causa confusión:

104
2017-05-23 12: 02: 46Z
  1. También puede evitar este redondeo al no intentar encontrar el "final" de un día de todos modos. > = 5 de mayo Y < El 6 de mayo es mucho más seguro y funcionará en cualquiera de los tipos de fecha /hora (excepto el TIEMPO, por supuesto). También sugiera evitar formatos regionales y ambiguos como m /d /aaaa.
    2014-02-11 19: 55: 02Z
  2. @ AaronBertrand: estoy totalmente de acuerdo, pero mirando la cantidad de preguntas que tenemos, vale la pena describir.
    2014-02-13 19: 54: 27Z
  3. ¿Por qué cambió de 20100505 a 5/5/2010? El formato anterior funcionará con cualquier región en SQL Server. Tél último se romperá: SET LANGUAGE French; SELECT Convert(datetime, '1/7/2015') oops: 2015-07-01 00:00:00.000
    2015-09-23 22: 35: 25Z
  4. @ EBarr: Re. "DateTime2 es el método preferido para avanzar. Tiene un rango de fechas más amplio, mayor precisión y utiliza almacenamiento igual o menor (dependiendo de la precisión": Estoy totalmente en desacuerdo. Consulte la sección Contras de mi Respuesta del 7/10/17 a continuación En resumen, es probable que esos beneficios sean innecesarios (fuera de las aplicaciones de ingeniería /científicas) y, por lo tanto, no valgan la pérdida de los beneficios. Número de días (incl. si aplica, fracciones desde min fecha-hora) valor para +, - y promedio.
    2017-08-10 23: 52: 27Z

DateTime2 puede causar estragos si eres un desarrollador de Access que intenta escribir Now () en el campo en cuestión. Acabo de hacer un acceso - > La migración a SQL 2008 R2 y colocó todos los campos de fecha y hora en DateTime2. Anexando un registro con Ahora () como el valor bombardeado. Estuvo bien el 1/1/2012 2:53:04 PM, pero no el 1/10/2012 2:53:04 PM.

Una vez el personaje hizo la diferencia. Espero que ayude a alguien.

    
15
2012-02-13 19: 52: 43Z

Este es un ejemplo que le mostrará las diferencias en el tamaño de almacenamiento (bytes) y la precisión entre smalldatetime, datetime, datetime2 (0) y datetime2 (7):

 
DECLARE @temp TABLE (
    sdt smalldatetime,
    dt datetime,
    dt20 datetime2(0),
    dt27 datetime2(7)
)

INSERT @temp
SELECT getdate(),getdate(),getdate(),getdate()

SELECT sdt,DATALENGTH(sdt) as sdt_bytes,
    dt,DATALENGTH(dt) as dt_bytes,
    dt20,DATALENGTH(dt20) as dt20_bytes,
    dt27, DATALENGTH(dt27) as dt27_bytes FROM @temp

que devuelve

 
sdt                  sdt_bytes  dt                       dt_bytes  dt20                 dt20_bytes  dt27                         dt27_bytes
2015-09-11 11:26:00  4          2015-09-11 11:25:42.417  8         2015-09-11 11:25:42  6           2015-09-11 11:25:42.4170000  8

Entonces, si quiero almacenar información hasta el segundo, pero no en milisegundos, puedo guardar 2 bytes cada uno si uso datetime2 (0) en lugar de datetime o datetime2 (7).

    
15
2015-10-26 14: 39: 38Z

Casi todas las respuestas y comentarios han sido pesados ​​sobre los pros y ligeros sobre los contras. Aquí hay un resumen de todos los Pros y Contras hasta ahora, más algunos Contras cruciales (en el # 2 a continuación) que solo he visto mencionados una vez o no.

  1. PROS:

1.1. Más compatible con ISO (ISO 8601) (aunque no sé cómo esto entra en juego en la práctica).

1.2. Más rango (1/1/0001 a 12/31/9999 vs. 1/1 /1753-12 /31/9999) (aunque el rango adicional, todos antes del año 1753, probablemente no se usará excepto por ej., en aplicaciones históricas, astronómicas, geológicas, etc.).

1.3. Coincide exactamente con el rango del rango del Tipo DateTime de .NET (aunque ambos se convierten de un lado a otro sin una codificación especial si los valores se encuentran dentro del rango y la precisión del tipo objetivo, excepto en el Con # 2.1 que se muestra a continuación; se producirá un error /redondeo).

1.4. Más precisión (100 nanosegundos, también conocido como 0,000,000,1 segundos, frente a 3,33 milisegundos, conocido como 0,003,33 segundos) (aunque es probable que no se use la precisión adicional, excepto para ej., En aplicaciones de ingeniería /científicas).

1.5. Cuando se configura para similar (como en 1 milisegundo no "igual" (como en 3.33 milisegundos) como Iman Abidi reclamó) precisión como DateTime, usa menos espacio (7 vs. 8 bytes), pero luego de Por supuesto, estaría perdiendo el beneficio de precisión, que es probablemente uno de los dos (el otro es el rango) más promocionado, aunque es probable que sea innecesario).

  1. CONS:

2.1. Al pasar un Parámetro a un .NET SqlCommand, debe especificar System.Data.SqlDbType.DateTime2 si puede pasar un valor fuera del rango y /o la precisión de SQL Server DateTime, porque su valor predeterminado es System.Data.SqlDbType.DateTime.

2.2. No se puede convertir de manera implícita /fácil a un valor numérico de punto flotante (# de días desde la fecha y hora mínimos) para hacer lo siguiente a /con él en expresiones de SQL Server usando valores numéricos y operadores:

2.2.1. sumar o restar # de días o días parciales. Nota: el uso de la Función DateAdd como solución alternativa no es trivial cuando necesita considerar múltiples, si no todas, las partes de la fecha y la hora.

2.2.2. tome la diferencia entre dos fechas y fechas para propósitos de cálculo de "edad". Nota: en su lugar, no puede simplemente usar la función DateDiff de SQL Server, ya que no calcula age como la mayoría de las personas esperaría si las dos fechas coinciden con un calendario /límite de la fecha y la hora del reloj de las unidades especificadas si incluso para una pequeña fracción de esa unidad, devolverá la diferencia como 1 de esa unidad frente a 0. Por ejemplo, el DateDiff en Day de dos fechas solo 1 la diferencia de milisegundos devolverá 1 frente a 0 (días) si esas fechas y fechas tienen días calendario diferentes (es decir, "1999-12-31 23: 59: 59.9999999" y "2000-01-01 00: 00: 00.0000000"). La misma fecha y diferencia de 1 milisegundo si se mueve para que no se crucen en un día calendario, devolverá un "DateDiff" en Day 's de 0 (días).

2.2.3. tome el Avg de fecha-hora (en una consulta agregada) simplemente convirtiendo primero a "Flotante" y luego nuevamente a DateTime.

NOTA: para convertir DateTime2 a un número, debe hacer algo como la siguiente fórmula que aún asume que sus valores no son menores que en el año 1970 (lo que significa que está perdiendo todo el rango adicional más otros 217 años). Nota: Es posible que no pueda simplemente ajustar la fórmula para permitir un rango adicional porque puede tener problemas de desbordamiento numérico.

25567 + (DATEDIFF(SECOND, {d '1970-01-01'}, @Time) + DATEPART(nanosecond, @Time) / 1.0E + 9) / 86400.0 - Fuente: “ https : //siderite.blogspot.com/2015/08/how-to-translate-t-sql-datetime2-to.html

Por supuesto, también puede Cast a DateTime primero (y si es necesario, volver a DateTime2), pero perdería los beneficios de precisión y alcance (todos anteriores al año 1753) de DateTime2 frente a DateTime, que son ampliamente los 2 más grande y al mismo tiempo, prolly los 2 menos necesarios, lo que plantea la pregunta de por qué usarlo cuando se pierden las conversiones implícitas /fáciles a números de punto flotante (número de días) para la suma /resta /"edad" (vs. DateDiff) ) /Avg calcs beneficio que es grande en mi experiencia.

Por cierto, el Avg de fecha-hora es (o al menos debería ser) un caso de uso importante. a) Además de su uso para obtener la duración promedio cuando se usan las fechas y horas (ya que se utiliza una fecha y hora base común) para representar la duración (una práctica común), b) también es útil para obtener una estadística de tipo tablero de control en la fecha promedio. la hora está en la columna fecha-hora de un rango /grupo de filas. c) Una consulta ad-hoc estándar (o al menos debería ser estándar) para monitorear /resolver problemas en una columna que puede que ya no sea válida por más tiempo y /o que deba ser desaprobada enumere para cada valor el recuento de ocurrencias y (si está disponible) las marcas de fecha y hora Min, Avg y Max asociadas con ese valor.

    
15
2017-08-10 23: 36: 00Z
  1. Al igual que la vista contraria, señala el lado c # de la ecuación. Combinado con todos los demás "profesionales", permitirá a las personas tomar una buena decisión en función de dónde quieren soportar su dolor.
    2017-08-11 15: 47: 13Z
  2. @ EBarr: Solo la parte de los Contras # 1 de mi "vista contraria '" "señala el lado c # de la ecuación". El resto (Contras # 's 2.2.1 - 2.2.3), que, como he dicho, son los beneficios más probables y necesarios (de DateTime), están relacionados con los efectos en las consultas y declaraciones de SQL Server.
    2017-08-12 01: 59: 36Z

La interpretación de las cadenas de fecha en datetime y datetime2 también puede ser diferente, cuando se usan configuraciones que no son las de US DATEFORMAT. Por ejemplo,

 
set dateformat dmy
declare @d datetime, @d2 datetime2
select @d = '2013-06-05', @d2 = '2013-06-05'
select @d, @d2

Esto devuelve 2013-05-06 (es decir, el 6 de mayo) para datetime, y 2013-06-05 (es decir, el 5 de junio) para datetime2. Sin embargo, con dateformat establecido en mdy, tanto @d como @d2 devuelven 2013-06-05.

El comportamiento del datetime parece estar en desacuerdo con el La documentación de MSDN de SET DATEFORMAT que indica: Algunos formatos de cadenas de caracteres, por ejemplo ISO 8601, se interpretan independientemente de la configuración DATEFORMAT . ¡Obviamente no es cierto!

Hasta que me mordió esto, siempre pensé que las fechas yyyy-mm-dd se manejarían correctamente, independientemente de la configuración de idioma /configuración regional.

    
9
2013-06-21 13: 11: 19Z
  1. No. Para ISO 8601, creo que quiso decir YYYYMMDD (sin guiones). SET LANGUAGE FRENCH; DECLARE @d DATETIME = '20130605'; SELECT @d; Inténtalo de nuevo con los guiones.
    2014-02-11 19: 57: 17Z
  2. El estándar permite los formatos YYYY-MM-DD y YYYYMMDD para las representaciones de fecha de calendario. Creo que MSDN debería ser más específico sobre qué subconjunto de la especificación ISO 8601 se interpreta de forma independiente.
    2014-02-11 22: 07: 02Z
  3. Lo sé, pero en SQL Server solo la sintaxis sin guiones es segura.
    2014-02-11 22: 17: 39Z

mientras hay una mayor precisión con datetime2 , algunos clientes no admiten fecha , hora o datetime2 y lo obligan a convertir a una cadena literal. Específicamente, Microsoft menciona problemas de ODBC, OLE DB, JDBC y SqlClient de "nivel inferior" con estos tipos de datos y tiene un gráfico que muestra cómo cada uno puede asignar el tipo.

Si el valor es compatible por encima de la precisión, use datetime

    
9
2014-06-25 20: 56: 15Z

Pregunta anterior ... Pero quiero agregar algo que no haya sido mencionado por nadie aquí ... (Nota: Esta es mi observación, así que no pida ninguna referencia)

Datetime2 es más rápido cuando se usa en criterios de filtro.

TLDR:

En SQL 2016 tenía una tabla con cientos de miles de filas y una columna de fecha y hora ENTRY_TIME porque era necesario almacenar el tiempo exacto en segundos. Mientras ejecutaba una consulta compleja con muchas uniones y una sub consulta, cuando usaba la cláusula where como:

 
WHERE ENTRY_TIME >= '2017-01-01 00:00:00' AND ENTRY_TIME < '2018-01-01 00:00:00'

La consulta estuvo bien inicialmente cuando había cientos de filas, pero cuando aumentó el número de filas, la consulta comenzó a dar este error:

 
Execution Timeout Expired. The timeout period elapsed prior
to completion of the operation or the server is not responding.

Eliminé la cláusula where, e inesperadamente, la consulta se ejecutó en 1 segundo, aunque ahora se recuperaron TODAS las filas para todas las fechas. Ejecuto la consulta interna con la cláusula where, y tomó 85 segundos, y sin la cláusula where tomó 0.01 segundos.

Encontré muchos subprocesos para este problema como rendimiento de filtrado de fecha y hora

Optimicé la consulta un poco. Pero la velocidad real que obtuve fue cambiando la columna datetime a datetime2.

Ahora, la misma consulta que se agotó antes lleva menos de un segundo.

saludos

    
7
2018-02-09 05: 08: 27Z

Según este artículo , si desea tener la misma precisión de DateTime con DateTime2, simplemente tiene que usar DateTime2 (3). Esto debería darle la misma precisión, ocupar menos bytes y proporcionar un rango expandido.

    
6
2014-08-18 18: 06: 41Z
  1. Para ser claros, tiene la misma precisión que el datetime de SQL, no un DateTime de .NET.
    2015-11-13 19: 06: 25Z
  2. Eso es correcto, asumí que todos entenderían el contexto, pero vale la pena expresarlo específicamente.
    2015-11-17 16: 01: 32Z

Acabo de encontrar una ventaja más para DATETIME2: evita un error en el módulo Python adodbapi, que explota si se pasa un valor de biblioteca estándar datetime que tiene microsegundos distintos a cero para una columna DATETIME pero funciona bien si la columna se define como DATETIME2.

    
4
2017-11-04 15: 31: 26Z
 
Select ValidUntil + 1
from Documents

El SQL anterior no funcionará con un campo DateTime2. Devuelve y el error "Operand type clash: datetime2 es incompatible con int"

Agregar 1 para obtener al día siguiente es algo que los desarrolladores han estado haciendo con las fechas durante años. Ahora Microsoft tiene un nuevo campo datetime2 que no puede manejar esta funcionalidad simple.

"Vamos a usar este nuevo tipo que es peor que el anterior", ¡no lo creo!

    
0
2017-05-25 09: 17: 38Z
  1. Solo para que quede claro aquí, los tipos de datos datetime y datetime2 se introdujeron en SQL Server 2008. También obtiene Operand type clash: date is incompatible with int del tipo date que ha existido desde el día punto. Sin embargo, los tres tipos de datos funcionan bien con dateadd(dd, 1, ...).
    2017-08-21 04: 35: 31Z
  2. Esto no está claro. Tengo una base de datos SQLServer 2005 con un campo de fecha y hora.
    2017-08-21 08: 35: 09Z

Creo que DATETIME2 es la mejor manera de almacenar el date, porque tiene más eficiencia que El DATETIME. En SQL Server 2008 puede usar DATETIME2, almacena una fecha y hora, toma 6-8 bytes para almacenar y tiene una precisión de 100 nanoseconds. Así que cualquiera que necesite una mayor precisión de tiempo querrá DATETIME2.

    
0
2019-05-17 09: 16: 10Z
fuente colocada aquí