Conversion binary(4) to datetime

salut tous le monde

j'ai une base de données SQL SERVER et dans une table y a un champ (dateRec) de type binary(4) que je veux convertir en datetime mais j'arrive pas a le faire, j'ai beau essayer avec

CAST OU CONERT EN SQL SERVER mais il me sort un message d'erreur :

Conversion failed when converting datetime from binary/varbinary string.

exemple :

select cast(0xC3041501 AS datetime)

0xC303104A
0xC3030614
0xC3024848
0xC3031962

merci d'avance.

Bonjour,

Il aurait été intéressant que vous donniez aussi les valeurs attendues ...

@++ ;)

Bonjour

j'ai aucune idée des valeurs mais je sais que c'est de type date a 100%.

merci

Bonjour,

je n'ai jamais stocké les dates en binary mais j'ai remarqué un truc bizarre :

Code:

---

1 2	SELECT cast(convert(datetime, '2013-31-12 13:23') as binary(4)), CAST(cast(convert(datetime, '2013-31-12 13:23') as binary(4)) As datetime)

---

Le code ci-dessus perd la date lors de l'affichage alors que le code ci-dessous fonctionne correctement ..

Code:

---

1 2 3

SELECT cast(convert(datetime, '2013-31-12 13:23') as binary(8)), CAST(cast(convert(datetime, '2013-31-12 13:23') as binary(8)) As datetime)

---

Je trouve ça curieux ...

bonjour

mais mon cas ce n'est pas de convertir une date en binary (4), c'est l'inverse .

bonjour,

Je ne pense pas que vos données soit une date, il doit y avoir une confusion.

En effet, la date max de SQL est représentée par la valeur suivante : '9999-12-31 23:59:59.997' qui en binary(4) à pour valeur 0x018B81FF.
Si je regarde les data que vous nous proposez, celles-ci sont très largement supérieures.

Les 2 requêtes que j'ai mis permettent de convertir dans les 2 sens :

Citation:

---

Résultat de la premiere :
- Colonne 1 : 0x00DC8CF0
- Colonne 2 : 1900-01-01 13:23:00.000

---

Citation:

---

Résultat de la seconde :
- Colonne 1 : 0x0000A2A500DC8CF0
- Colonne 2 : 2013-12-31 13:23:00.000

---

Le résultat est bizarre non ?

Et je posais une question concernant la taille du binary. Ma version de sqlserver ne converti pas correctement un champ datetime en binary (4). Cela ne fonctionne qu'à partir de binary(6) en fait. Est-ce normal ?

Sinon tu peux essayer la fonction 'try_convert' au lieu de convert afin de vérifier si certaines valeurs fonctionnent.
Voila je trouve les valeurs bizarres.

BONJOUR

mais c'est bien une date car le champ (daterec) est une date de recrutement des salariés.

C'est une date et pas un datetime alors ?

essaye ça : cast(0xC3041501 AS date)

c'est la même chose mais avec un autre message d'erreur :

Conversion failed when converting date and/or time from character string.

Pour ton jeu de données (les 4 pseudo dates sur 4 bytes) y'aurait moyen d'avoir les valeurs date renvoyées par ton programme ?

En effet, 32 bits pour stocker une date, ça ressemble beaucoup au TIMESTAMP d'Unix.

Seulement la valeur 0xC303104A (3271757898) correspond au 4/9/2073 à 14:38:18 ce qui n'est pas franchement possible comme date d'embauche.

On va pouvoir essayer toutes les combinaisons possible sans forcément trouver la bonne... Il faudrait déjà avoir un exemple de valeur avant/après encodage histoire de savoir comment elle est encodée...

-- Edit : Si j'enlève 70 ans à la date du timestamp standard, je tombe sur une date cohérente... Du coup ça "pourrait" être une date exprimée en nombre de secondes depuis le 01/01/1900

Mais impossible d'en avoir la certitude tant que tu ne confirmes pas les dates présentes dans ton application.

En tout cas, ça y ressemble beaucoup (le type datetime de SQL Server peut être converti en double sous la forme "secondes depuis 01/01/1900 . fraction du jour")

Code:

---

1 2	select cast(cast(cast(0xC303104A as bigint) as decimal) / 60 / 60 / 24 as datetime)

---

-- Edit 2 : Quoique non en fait... Car avec les 4 dates données en exemple, les 4 personnes ont été embauchées à quelques heures d'intervalle, et surtout y'en a une qui a été embauchée en pleine nuit !

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

with dates (dte) as ( select 0xC303104A union all select 0xC3030614 union all select 0xC3024848 union all select 0xC3031962 ) select cast(cast(cast(dte as bigint) as decimal) / 60 / 60 / 24 as datetime), cast(cast(cast(dte as bigint) / 60 / 60 / 24 as datetime) as date) from dates

---

Code:

---

1 2 3 4 5

2003-09-05 13:38:18.000 2003-09-05 2003-09-05 12:54:44.000 2003-09-05 2003-09-04 23:24:56.000 2003-09-04 2003-09-05 14:17:06.000 2003-09-05

---

C'est une base d'un client que je doit la transférer dans une autre base du cout j'ai pas les valeurs affichées.

Alors si tu ne peux pas comparer les données dans la table et les données à l'écran, comment peut-tu être certain que c'est bien la date d'embauche ?

Et surtout... Comment être certain (vu que c'est stocké comme un chien fou sa merde) que la colonne ne contient QUE ta date ? Car les données ne sont clairement pas cohérentes de prime abord...

Si on part du principe que c'est un entier 32 bits, et qu'on compare les nombres entre eux :

Le plus grand - le plus petit = 53530

Si on part du principe que ce sont des jours, cela fait un delta de 146 ans
Ça semble très étrange.

Si c'est des heures, non seulement ça fait plus que 6, ce qui semble au contraire petit, surtout vu la tronche de la base, qui semble toute droit sortie d'un cerveau retraité des années 70, mais en plus je ne vois pas trop l'intérêt de stocker la date d'embauche à l'heure prêt... et pas à la minute et seconde !

Si je pars du principe que la gars qui a fait ça est un autiste des années 70, on peut se dire que son 32 bits est stocké en "big endian".
ce qui donne, après conversion à partir du type timestamp les dates suivantes :

1978-08-30 14:24:03.000
1973-03-27 19:58:59.000
2008-06-07 04:54:26.000
1983-07-01 10:20:51.000

La plage de date ne semble pas trop déconnante (m'enfin un peu quand même). On se demande en revanche pourquoi le gars embauché en 2008 l'a été à 4 heures du matin !

Bref, on va pas s'en sortir sans avoir les données "lisibles" à côté.

-- Edit : Accessoirement, on peut espérer que le gars ait stocké une sérialisation "as is" du type de données applicatif... C'est quoi le langage dans lequel est programmée l'application ?

je vais essayer d'avoir les valeurs au près du client et je revient vers vous

merci de ton aide a plus

Bonjour

j'ai le même cas que la date mais cette fois c'est la conversion d'un champ binary(10) en float

exemple:

0x0000000002631320000C =2631.32
0X0000000005004350000C =5004.35
0X0000000122330300000C =122330.30

MERCI D'AVANCE

Tu es sûr que c'est bien ça la conversion ?

Car là, c'est des grands malade les gars...

J'aurais tendance à dire :

Code:

---

1 2 3

select val, cast(substring(master.dbo.fn_varbintohexstr(val), 3, 19) as float) / 1000000 from bin

---

Ce qui donne :

Code:

---

1 2 3 4

0x0000000002631320000C 2631,32 0x0000000005004350000C 5004,35 0x0000000122330300000C 122330,3

---

Mais là franchement c'est hors concours ! Y'a des dégénérés congénitaux qui sévissent, mais je n'imaginais pas à ce point là !

Le "C" à la fin, c'est pour "currency" ? Genre c'est un prix ?

Bonjour tous le monde

je reviens vers vous au sujet de la conversion d'un champ binary(4) en datetime , j'ai pu avoir des exemple concret les voila:

0xC3030836 ------------->22/06/1985

0xC3041349 ------------->01/12/2014

merci d'avance

BONJOUR

SVP quelqu'un peu m'aidé à ce sujet de conversion

Bonjour tous le monde

je viens vers vous au sujet de la conversion d'un champ binary(4) en datetime , j'ai pu avoir des exemple concret les voila:

0xC3030836 ça donne 22/06/1985

0xC3041349 ça donne 01/12/2014

merci d'avance

Bonsoir,

J'avoue que je ne vois pas du tout quel cheminement permet de passer de la valeur binaire à une date.

Si on soustrait les deux valeurs, on tombe sur "0x010B13"
Ce qui correspond à 68371 en décimal.

Ce ne sont pas des jours, car 68371 / 365.25 = 187,1895962 soir 187 ans.
Hors, entre 1985 et 2014 on est loin d'avoir 187 ans...

Donc exit la conversion "date pivot + nombre de jours".

Si on effectue les soustractions byte par byte, on se retrouve avec :

0xC3 / 0x03 / 0x08 / 0x36 => 195 / 3 / 8 / 54
0xC3 / 0x04 / 0x13 / 0x49 => 195 / 4 / 19 / 73

73 - 54 = 19
19 - 8 = 11
4 - 3 = 1
195 - 195 = 0

On se retrouve avec une différence de 1 unité, 11 autres unités et 19 autres unités.
2014 - 1985 = 29
12 - 6 = 6
1 - 22 = 10 (en partant du principe qu'il y a un modulo 31 pour les jours)

BREF : rien à voir avec la choucroute !

Ho putain !

J'ai peut-être une idée.

Imaginons un mongolien qui n'a rien compris à la représentation hexa.
Et qui donc fait des calculs décimaux sur des valeurs hexa.

Il préfixe ces dates par "C3" histoire de se rappeler que c'est son "idée de crétin numéro 3".

Et on arrive donc à :

30836 ------------->22/06/1985

41349 ------------->01/12/2014

Si je fais 41349 - 30836 j'obtiens 10513

Si je divise 10513 par 365,25 j'obtiens environ 28,78 ans ce qui semble pas trop mal (enfin, presque)

Hors, du 22/06/1985 au 01/12/2014 on a 10754 jours... (29,44 ans)

Mardouille... Je croyais avoir percé le secret de l'autiste... Encore raté :D

Hmmmm... Sinon, juste un truc bête comme ça en passant...

Ton pseudo fait quelque peut référence à la religion musulmane.
Ton programme aurait-il pu être écrit par un musulman en se basant sur une représentation calendaire non occidentale (calendrier hégirien ?)

Car si on parle en phase de lunes, ça pourrait expliquer pourquoi un bête décompte de jours en années ne fonctionne pas.

En tout cas, sans plus d'éléments, j'ai plus de flèche à mon arc.

Autre possibilité (mais là ce serait énorme) : la colonne binaire fait référence à la clé primaire d'une table fourre-tout qui contient en identifiant cette valeur rattachée à la date... A creuser aussi peut-être.