Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Difference de 2j dans les conversion de dates

10 réponses
Avatar
Arnaud
Bonjour a tous
j'ai une table dans laquelle est stockée une date sous la forme
'39449.632118055597' (float) ...

si je fais la conversion dans Excel, j'obtiens
02/01/2008 15:10

si je fais une requete avec cast(mazonedate as DATETIME) j'obtiens
'2008-01-04 15:10:16.997'

d'ou vient cette différence de 2 jours ?

Merci de votre aide

10 réponses

Avatar
Thierry
Excel est buggée en la matière.
Par exemple le nombre 60 renvoi le 29/2/1900. Hors, cette date n'a jamais
existé. l'année 1900 n'était pas bissextile.

Sinon, il n'y a pas de norme pour dire si : 0 = 1/1/1900 ou 1 = 1/1/1900.


--
Thierry


"Arnaud" a écrit dans le message de news:

Bonjour a tous
j'ai une table dans laquelle est stockée une date sous la forme
'39449.632118055597' (float) ...

si je fais la conversion dans Excel, j'obtiens
02/01/2008 15:10

si je fais une requete avec cast(mazonedate as DATETIME) j'obtiens
'2008-01-04 15:10:16.997'

d'ou vient cette différence de 2 jours ?

Merci de votre aide




Avatar
Arnaud
Mauvais exemple , 1900 est une exception, ainsi que 2100 d'ailleurs ...
Qu'est-ce qui me permet de dire que c'est excel qui est dans le faux,
et pas SQL ...?


Dans son message précédent, Thierry a écrit :
Excel est buggée en la matière.
Par exemple le nombre 60 renvoi le 29/2/1900. Hors, cette date n'a jamais
existé. l'année 1900 n'était pas bissextile.

Sinon, il n'y a pas de norme pour dire si : 0 = 1/1/1900 ou 1 = 1/1/1900.


--
Thierry


"Arnaud" a écrit dans le message de news:

Bonjour a tous
j'ai une table dans laquelle est stockée une date sous la forme
'39449.632118055597' (float) ...

si je fais la conversion dans Excel, j'obtiens
02/01/2008 15:10

si je fais une requete avec cast(mazonedate as DATETIME) j'obtiens
'2008-01-04 15:10:16.997'

d'ou vient cette différence de 2 jours ?

Merci de votre aide






Avatar
Thierry
Si on part du principe que 1/1/1900 = 0, il n'y a pas d'incohérence dans SQL
Serveur

Dans Excel, si on part du principe que 1/1/1900=1, il y a un décalage 1j à
partir du 1/3/1900.

--
Thierry


"Arnaud" a écrit dans le message de news:

Mauvais exemple , 1900 est une exception, ainsi que 2100 d'ailleurs ...
Qu'est-ce qui me permet de dire que c'est excel qui est dans le faux, et
pas SQL ...?


Dans son message précédent, Thierry a écrit :
Excel est buggée en la matière.
Par exemple le nombre 60 renvoi le 29/2/1900. Hors, cette date n'a jamais
existé. l'année 1900 n'était pas bissextile.

Sinon, il n'y a pas de norme pour dire si : 0 = 1/1/1900 ou 1 =
1/1/1900.


--
Thierry


"Arnaud" a écrit dans le message de news:

Bonjour a tous
j'ai une table dans laquelle est stockée une date sous la forme
'39449.632118055597' (float) ...

si je fais la conversion dans Excel, j'obtiens
02/01/2008 15:10

si je fais une requete avec cast(mazonedate as DATETIME) j'obtiens
'2008-01-04 15:10:16.997'

d'ou vient cette différence de 2 jours ?

Merci de votre aide










Avatar
Fred
Dans : news:,
Arnaud disait :
Mauvais exemple , 1900 est une exception, ainsi que 2100 d'ailleurs



Pourquoi sont-ce des exceptions ? 1900, 2000 et 2100 me semblent
parfaitement conformes à la règle de calcul des années bissextiles.
Un année bissextile tous les 4 ans
Sauf tous les débuts de siècle
Sauf tous les 4 siècles.

--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Avatar
Arnaud
une petite recherche dans google (qui est ton amis)
nous donne ce resultat :
je cite "Il est néanmoins resté d'utilisation générale en Europe
jusqu'à la promulgation, en 1582, par le pape Grégoire XIII, du
calendrier grégorien. Rapidement adopté par la plupart des pays
catholiques, le nouveau calendrier, qui reste le nôtre, apporta un
ajustement en décidant de supprimer les années bissextiles pour les
années qui sont des multiples de 100 sans être des multiples de 400.
Ainsi, 2000 ou 2004 sont des années bisextiles, contrairement à 1900 et
à 2100, par exemple."

voili voilou ...


Le 07/01/2008, Fred a supposé :
Dans : news:,
Arnaud disait :
Mauvais exemple , 1900 est une exception, ainsi que 2100 d'ailleurs



Pourquoi sont-ce des exceptions ? 1900, 2000 et 2100 me semblent parfaitement
conformes à la règle de calcul des années bissextiles.
Un année bissextile tous les 4 ans
Sauf tous les débuts de siècle
Sauf tous les 4 siècles.


Avatar
Fred
Dans : news:,
Arnaud disait :
une petite recherche dans google (qui est ton amis)
nous donne ce resultat :
je cite "Il est néanmoins resté d'utilisation générale en Europe
jusqu'à la promulgation, en 1582, par le pape Grégoire XIII, du
calendrier grégorien. Rapidement adopté par la plupart des pays
catholiques, le nouveau calendrier, qui reste le nôtre, apporta un
ajustement en décidant de supprimer les années bissextiles pour les
années qui sont des multiples de 100 sans être des multiples de 400.
Ainsi, 2000 ou 2004 sont des années bisextiles, contrairement à 1900
et à 2100, par exemple."

voili voilou ...



Oui, c'est ce que j'ai écrit :-)

--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Avatar
Arnaud
admettons ...
ce qui ne fait pas avancer mon pb ...

Fred avait écrit le 07/01/2008 :
Dans : news:,
Arnaud disait :
une petite recherche dans google (qui est ton amis)
nous donne ce resultat :
je cite "Il est néanmoins resté d'utilisation générale en Europe
jusqu'à la promulgation, en 1582, par le pape Grégoire XIII, du
calendrier grégorien. Rapidement adopté par la plupart des pays
catholiques, le nouveau calendrier, qui reste le nôtre, apporta un
ajustement en décidant de supprimer les années bissextiles pour les
années qui sont des multiples de 100 sans être des multiples de 400.
Ainsi, 2000 ou 2004 sont des années bisextiles, contrairement à 1900
et à 2100, par exemple."

voili voilou ...



Oui, c'est ce que j'ai écrit :-)


Avatar
Fred
Dans : news:,
Arnaud disait :

Pour en revenir à ta question.
Pour Excel : le 01/01/1900 est égal à 1
Pour SQL Server c'est zéro (les datetimes sont stockés sous forme de
deux entiers de 4 octets dont le premier représente le nombre de jours
de différence avec l'origine)
Donc, dès le départ, un «jour» d'écart (SELECT CAST(0 AS DATETIME))
Si tu ajoutes l'erreur d'Excel concernant l'année 1900, on se retrouve
bien à deux, non ?

--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Avatar
Fred
Dans : news:,
Arnaud disait :
admettons ...
ce qui ne fait pas avancer mon pb ...



Thierry a donné la raison de ce décalage !
Bon, j'espère que mes petits détails complémentaires vont aider alors
:-)

--
Fred
http://www.cerber mail.com/?3kA6ftaCvT (enlever l'espace)
Avatar
Arnaud
Ah ok, maintenant j'ai compris ...
Merci beaucoup, j'inclus donc -2 dans mes requetes

Après mûre réflexion, Fred a écrit :
Dans : news:,
Arnaud disait :

Pour en revenir à ta question.
Pour Excel : le 01/01/1900 est égal à 1
Pour SQL Server c'est zéro (les datetimes sont stockés sous forme de deux
entiers de 4 octets dont le premier représente le nombre de jours de
différence avec l'origine)
Donc, dès le départ, un «jour» d'écart (SELECT CAST(0 AS DATETIME))
Si tu ajoutes l'erreur d'Excel concernant l'année 1900, on se retrouve bien à
deux, non ?