Editar: Sorprendido por la respuesta de Jarr que investigarse más a fondo. Resulta que los puntos de tiempo de ejemplo sharhar_m da en la pregunta son incorrectos (lo siento por no haber verificado eso antes).
En resumen, la función dada en la pregunta está desactivada de 367-281 = 86 días y deben ser corregidos a
function cstime = datenum2datetime(matlabSerialTime)
cstime = 10^7*60*60*24*(matlabSerialTime - 367);
Ahora a los detalles, en el caso Alguien está interesado: Usted reclama
% {05-Feb-2011 11:19:15} en System.DateTime es 6 34399319550000000
pero en MATLAB R2010b
sdt =System.DateTime(634399319550000000);
[sdt.Day sdt.Month]
vuelve [2 5]
, por lo que su valor DateTime es en realidad para el 2 de mayo no Feb 5 ª !! Para calcular los valores correctos, establezca
cs_times = [System.DateTime.Parse('05-Feb-2011 11:19:15').Ticks ...
System.DateTime.Parse('05-Feb-2011 12:07:24').Ticks]
que da [634325015550000000 634325044440000000]
.
unidad de escalado en el tiempo
Su factor de a
es 10^7 * 60 * 60 * 24 es decir, las tiendas de MATLAB la fecha/hora en las unidades de "día" (con el tiempo como días fraccionarios) y C# tiendas tiempo como "ticks", es decir, el número de "10^-7 segundos". Probablemente pueda evitar algunos errores de redondeo introduciendo el valor preciso para a
.
diferencia en el punto de tiempo de referencia
El desplazamiento b
expresado en días (b/a
) le dice que su "origen del tiempo" es de 367 días de diferencia; con su valor anterior para b
esto salió a 281 días. La documentación de MATLAB para datestr
afirma
"Un número de fecha serie representa la conjunto y número fraccionario de días de 1-Ene-0000 a una fecha específica. el año 0000 no es más que un punto de referencia y es no pretende ser interpretado como un año real en el tiempo."
(a pesar de correr datestr(0,'dd-mm-yyyy HH-MM-SS')
revela que el punto de referencia es en realidad 0-Ene-0000). C# ticks son el
" número de intervalos de 100 nanosegundos que han transcurrido desde 12:00 : 00 medianoche, 1 de enero de 0001, que representa DateTime.MinValue. No no incluye el número de garrapatas que son atribuibles a saltar segundos."
Así que en resumen, el 'origen en el tiempo' entre ambos sistemas se diferencia por un salto año y un día, por lo tanto, 367 días. Si realmente quisiera lidiar con fechas reales que datan de hace mucho tiempo, tendría que tomar la reforma Gregorian calendar y la corrección de Augustus a la aplicación incorrecta de años bisiestos en el Julian calendar antes del año 8 en cuenta ... pero dudo que esto sea de interés aquí ;-).
En caso de que todavía utilice la función anterior en cualquier lugar, asegúrese de leer mi respuesta actualizada (y la respuesta de jbarr que me señaló el problema). ** ¡Su código actual está desactivado en 86 días! ** –