Je convertit une date d'heure à l'odnate. Je m'attendais à obtenir exactement la même datetétime lors de la conversion de l'OADATE, mais il n'a que la résolution de milliseconde, et est donc différente. Ticks à partir d'A: 634202170964319073 Ticks de B: 634202170964310000 L'ODATE Double: 40437.290467951389 Quelle est la raison de cela? La résolution de DateTime est clairement assez bonne.
3 Réponses :
a probablement quelque chose à voir avec la précision du double, pas la datetime.
Le double converti est 40437.290467951389, semble assez précis, mais vous pourriez être correct.
Oui, le double serait suffisamment précis, mais à cause du double du double est stocké, il n'y a pas une représentation exacte de la dateTime comme un double.
@Ezombort Il semble préciser uniquement à cause du facteur de conversion entre les secondes et les jours. Si vous multipliez le double vous mentionnez, par 24.0 * 60.0 * 60.0 , vous ne verrez que trois décimales. Un "code arbitraire" double de cette magnitude affichera cinq décimales (ou sept décimales si vous affichez avec .tostring ("r") ). Donc, la précision complète d'un double n'est pas utilisée. Voir ma nouvelle réponse.
La méthode statique appelée par ToAfoate divise clairement les tiques de 10000, puis stocke le résultat dans une longue, supprimant ainsi toute info Milliseconde
Est-ce que quelqu'un sait où trouver les spécifications du format ODATE?
Pas exactement des spécifications, mais cela vaut la peine de lire: blogs.msdn.com/b/ericlippert/archive/2003/09/16/...
Je pense que c'est une excellente question. (Je viens de le découvrir.)
Sauf si vous travaillez avec des dates assez proches de l'année 1900, un Voici un travail-autour de: P> DateTime code> aura une précision em> supérieure à une date d'oe. Mais pour une raison obscure, les auteurs du DateTime CODE> STORT JUST DateTime code> et autre chose . Inutile de dire, faire cela jette beaucoup de précision sans raison sans raison. P> double ourOADate = ourDT.ToOADatePrecise();
// .ToString("G") gives 40437.2904679619
// .ToString("R") gives 40437.290467961888
Et cela était pire. Il y a des années, j'ai trouvé un bug où parfois des dates seraient arrondies à la milliseconde la plus proche, et cela pourrait éventuellement induire une erreur de deux jours. Heureusement, je pense que cela a finalement été corrigé.
Salut @jeppe - Merci pour cette excellente rédaction. Comment est le calcul math.pow (2.0, -37,0) jours, ou environ 0,6286 μs pour la date d'oa dérivée? Je ne parviens pas à envelopper ma tête autour de ça :-)
@Martin BA, la date d'automatisation OLE est mise en œuvre en tant que numéro de point flottant binaire de la double précision (64 bits) dont la valeur est le nombre de jours de minuit, le 30 décembre 1899. Point flottant signifie le nombre de bits disponibles pour le La partie fractionnée dépend de la taille de la partie entière du nombre. Comme vous le voyez ci-dessus, la partie entière de notre exemple est 40437. Tant qu'il se situe entre 32768 et 65535, il reste 37 bits pour la partie fractionnée et la précision que j'ai mentionnée est tirée.