Convertion de date en hexadicimale

[herve 74]

Bonjour à tous

Comment fait on pour convertir une date en hexadecimale.
Ex 12/03/01=2A77 :hum:
Merci.

[Anonyme]

Déc. hexa
12 : B
3 : 3
2001 : 7D1

12/03/2001 => B/3/7D1
Mais je doute que ce soit ce que tu demandes

Une date ne s'exprime pas en hexa; ce qui peut s'exprimer en hexa c'est le délai écoulé entre la date de référence de ton calendrier et la date du jour. Ce délai est un nombre entier de jours, exprimable en décimal, hexa, binaire, ...
2A77 en hexa, c'est 10871 en décimal.
12/03/2001 serait donc le 10871 ème jour dans ton référentiel de temps.
ce qui fait remonter ton référentiel à .....

Pour passer de l'hexa en décimal
2A77 :2*16^3 + 10*16^2 + 7*16^1 + 7*16^0 (^puissance)

Pour passer du décimal en hexa
Déc => hexa : division successive par 16
21 en décimal : 21 / 16 = 1 reste 5 => 15 en hexa (1*16^1 + 5*16^0)
30 en décimal : 30 / 16 = 1 reste 14 => 1E en hexa (1*16^1 + 14*16^0)

Ha oui ! du décimal en hexa :
1 => 1; 2 => 2; ..... ; 9 => 9; 10 => A; 11 => B; 12 => C; 13 => D; 14 => E; 15 => F; et 16 => 10 (1*16^1 + 0*16^0)

A+

[Anonyme]

petite erreur :
Déc. hexa
12 : C
3 : 3
2001 : 7D1

12/03/2001 => C/3/7D1

[Chimerade]

Je crois bien qu'il y a pas mal de façons de repérer le temps dans les ordinateurs, selon les logiciels utilisés. Certains comptent, par exemple, en semaine et jours, depuis une "certaine date" 0, d'autres en jours, d'autres...
J'ai entendu dire, autre exemple, que le bug de l'an 2000 n'était pas le seul du genre : certains logiciels sont susceptibles d'arriver sur leur bug perso à une certaine date pas tellement éloignée : il s'agirait d'un champ qui compte les jours (ou les semaines) avec un nombre de bits limités, ce qui fait que lorsque le champ sera plein, cela ramènera toutes les dates à 0, d'où catastrophe potentielle pour les logiciels qui se fondent sur ce calendrier ...

Bref, cela veut dire pour moi, que ta question peut bien être un casse-tête pour quelqu'un qui voudrait bien chercher toutes les possibilités de codage possible (!), mais s'il s'agit de répondre sérieusement, en ce qui me concerne, je n'ai aucune idée de la définition que tu cherches...

[Anonyme]

En informatique, dans le ventre des programmes, il n'y a que des délais.
Pour des besoins de compréhension humaine et de gain de temps pour éviter les recalculs à chaque fois, les délais sont stockés sous forme de date j/h/a.

Toute la question repose sur le point de temps origine et sur le pas de calcul (jour, minute, mois, nano s, ...) qui sont des choix de gestion.

Il y a donc au moins 3 questions à se poser :
quel temps origine (date (1/1/1900 ?), date événementielle (date ouverture d'un contrat, ...))
quel pas ? jour, mois, semaines, périodes, ....
quel codage ? hexa, octal, décimal, binaire, par codes, ...

Ensuite, il y a aussi les bugs physiques (taille des registres ou des compteurs) et les bugs logiciels (j'ai vu un compteur à 1 chiffre pour un nombre d'enfants dans un logiciel de paye : un brave homme avec 10 enfants a vu ses primes et droits afférents supprimés !!!! )

Et ne pas oublier, avec la mondialisation, deux dates différentes à la même date !! A 18h aujourd'hui à paris, il est 1 h le lendemain au japon : quelle est l'heure d'enregistrement d'un événement au japon dans les systèmes à paris ?
En cas de back-up, cela créé des situations cocasses parfois lourdes de conséquences dans des séries de types paris 18h - tokyo 1h - paris 19h !!!!
Il convient alors de gérer la date / heure de l'événement de gestion et la date / heure "universelle" de référence de l'input dans les systèmes pour introduire la notion de chronologie des événements à référence de dates multiples simultanées.

Nous sommes bien loin du seul problème de conversion hexa / décimal, qui n'est qu'une "péripétie" de convention d'écriture !!!