Codage de l'heure ..

bonjour ,

Existe il un algorithme permettant de coder la date et l'heure de window sous forme numérique , sur 6 digit max et en conservant l'ordre croissant des valeur numerique en fonction du temps ?

Le but n'est pas de retrouver l'heure d'apres cette forme numèrique , mais seulement de generer une suite de valeur numerique croissante en fonction du temps.

le but est de gerer un chrono ( une liste numérique ) de la creation de fichiers . et on ne veut pas stocker cette valeur sur le disque d'ou l'utilisation de la date.

merci d'avance

En langage C, il existe une fonction qui retourne le nombre de secondes depuis une date fixe (le 1er janvier 1970 je crois).
Donc, connaissant une date, on peut calculer le nombre de secondes, et récirpoquement, connaissant ce nombre de secondes, on peut retrouver la date correspondante.
Cette fonction doit plus ou moins exister dans n'importe quel langage.
Cela dit, sur 6 digit, cela ne doit pas etre faisable ...

salut , oui en effet çà existe aussi en delphi !

en ce moment je me trouve avec deux valeurs , aprés retait des infos non utiles , il me reste :
- une valeur de [0..9999] pour determiner la date .
- une valeur de [0..99999] pour determiner l'heure .

mais j ai un maximun de 9 digits .

je me demandai si il y avait pas une astuce , avec ces deux valeurs d'en determiner une 3 eme qui soit plus petite en taille de digit tout en respectant la chronologie

Bonjour,

Tu veux la date et l'heure sur 6 chiffres...

Au mieux, en ne faisant un calendrier qui n'est valable que pendant 99 ans, tu vas coder la date de la facon qui suit, en base 10 :
jjmmaa

Si au lieu de chiffres tu peux utiliser une chaine de 6 caractères, tu as la solution suivante :

Si tu te mets en base 36 (c'est à dire que tes chiffres seront 0, 1, .., 9, A, B, .., Z), tu peux réduire ca à 4 chiffres : jmaa

Dans ce cas, il te reste 2 chiffres disponibles. Sur le premier, tu peux coder l'heure. On arrive donc à : jmaah
En revanche, comme tu as 60 minutes mais seulement 36 symbloes (10 chiffres et 26 lettres), il te faut 2 chiffres en base 36 pour représenter les minutes.
Le fait de distinguer les majuscules des minuscules te permettant d'ajouter 26 caractères, tu arrives à 62 chiffres (0, .., 9, A, .. Z, a, .. z), ce qui te permet d'obtenir une "date" codée de la forme suivante :
jmaahm

Tu obtiens ainsi un "calendrier" te permettant de compter sur 3844 ans.

Ensuite, il y a juste l'affichage de la date dans un format compréhensible par un humain à gérer, mais ca doit être tout à fait faisable.

la réponse est jolie et bien pensée
mais je me demande s'il n'y a pas confusion entre la chaine restitutée
en base 200 par exemple on pourrait écrire 199 en mettant [FONT=Arial]Ç[/FONT]
qui ne fait bien q"un caractère à l'affichage mais qui nécessite un octet
pour écrire
si bien que d'aprés mes calculs (je suis pas trop sur) on ne doit pas pouvoir écrire en moins de 5 octets en base 256 si on veut une précision de l'ordre de la seconde
on gagne 3 octets par rapport à la représentation standard qui a une précision supérieure
au prix du disque dur cela me parait cher payé compte tenu de la perte de
l'accés aux fonctions intégrées
pour une liste numérique chrono un nuéro séquentiel utilisant un long
serait codé sur 4 octets
si c'est bien l'ordre chrono que l'on recherche et non la date elle même

Bonjour,

Citation:

---

Envoyé par random

la réponse est jolie et bien pensée

---

Merci beaucoup. Je trouve ca joli aussi ;)

Citation:

---

Envoyé par random

mais je me demande s'il n'y a pas confusion entre la chaine restitutée

---

C'est fort possible.

Concernant le nombre d'octets utilisé, sauf erreur, la question posée est sur "6 digits", que j'ai basiquement traduit par chiffre. Je ne me suis effectivement jamais posé la question des octets utilisés, ni même du fait que la solution proposée demande l'utilisation de chaines de caractères, ce qui n'est pas forcément possible.

Citation:

---

Envoyé par random

au prix du disque dur cela me parait cher payé compte tenu de la perte de l'accés aux fonctions intégrées

---

Je pense que le but n'est pas de gagner de la place sur un disque dur, mais plus sur une représentation mémoire, ou quelque chose dans ce goût là.

En tout cas, il est certain que la solution de changer de base pour avoir plus de caractères nécessite des traitements lourds, qui risquent d'être couteux en processeur et/ou mémoire utilisée.

Re bonjour ,

quelque explication supplementaire ..

- Non le but n'est pas de gagner de la place sur le disque ou meme des problemes de memoires .

- Les 6 digits ( donc 6 caractere ) sont juste pour m'adapter a un principe qualité déja etabli dans cette société et qui gere ses chronos sur ce nombre de digits.

- Le but n'est pas non plus de retrouver la date depuis cette valeur , mais juste d'etablir un ordre croissant de creation de fichier dans le temps.
( le fichier ID:620 est anterieur au fichier ID:1245 c'est tout , on cherche pas a savoir quand il a ete crée )

- Pourquoi ne pas utiliser un simple fichier dans lequel je stoke la valeur et que j'incremente quand il le faut ? , parceque un crach du disque ferai perdre le chrono ( poste local , pas de reseau , pas toujours de sauvegarde !! )

- Ensuite la lecture de cette valeur soit etre facilement identifiable par tout le monde ( d'ou la valeur numerique ) un changement de base risque de compliquer la lecture pour des gens non habitué a l'hexa par exemple

mais si une personne a une autre idée pour arriver au meme resultat je suis prenneur aussi .
sinon ben c'est impossible !

merci de vos reponse .

Ok, donc j'avais rien compris... Tant pis !

Pour ton système, si tu ne peux pas stocker les données sur disque parce que tu risques de perdre l'information, alors non, il n'existe pas de solution.

En effet, une autre solution aurait été de mettre les infos dans un segment de mémoire partagée, et de synchroniser ca avec le disque.

Mais le segment de mémoire partagée est en RAM, et donc les données sont perdues en cas de simple reboot de la machine.
Et pour ce qui est du disque, comme tu l'as dit, en cas de crash de celui-ci les données sont perdues.

Ceci dit, si le disque crash, tes fichiers aussi seront perdus, donc je suis pas sur que ce soit si grave que ca de stocker les infos sur le disque dur...

Sans compter que le passage à l'heure d'hiver risque de poser des problèmes de nom de fichier :?

dans ces conditions
j'ai deux piles les documents reçus en fifo
les documents estampillésen lifo

puis je lire dans les conditions qui te sont imposées le dernier
document estampillé et récupérer son estampille ?
si oui je lui ajoute 1
et j'estampille le premier reçu que je classe en estampillé

je ne comprends pas pourquoi le crash du disque dur m'interdirait quoi que soit (poste local , pas de reseau , pas toujours de sauvegarde !! )
puisque si les documents ont disparu je me bats l'oeil de leur index
et que si les documents existent toujours je peux reconstituer l'estampille
utile


par ailleurs une société dans laquelle c'est la norme (qui me semble d'ailleurs assez peu judicieuse) doit avoir des réponses et un savoir faire

Pour un courrier international les problèmes d'heure (temps universel)
soulevés plus haut sont à prendre en considération