[VC++6]Conversion de date

**ben_popcorn** · 19/12/2006, 14h13

Bonjour,

j'ai une date au format AAAAMMJJ stock�e dans une variable de type double.
Je dois calculer � partir d'une date de ce type, le jour de la veille, ce qui n'ets pas simple ...
COmment puis-je convertir cette variable de type double en format de date manipulable plus facilement ?

merci ;-)

ben

**Jan Rendek** · 19/12/2006, 14h20

Voila un �l�ment de r�ponse :
un double c'est 8 octets contig�s, il peut donc �tre manipul� comme un tableau de 8 octets

**Feriaman** · 19/12/2006, 15h29

Salut,

Quel format de date penses-tu utiliser ? Comment le d�crirais-tu ?

Comment ferais-tu � la main pour transformer ton double en quelque chose dans ce format-ci ?

Bonen r�flection.

**loufoque** · 19/12/2006, 22h58

Je dois calculer � partir d'une date de ce type, le jour de la veille, ce qui n'ets pas simple ...

Il suffit d'enlever un jour.
Bien s�r, il est possible que du coup tu aies � passer au moins pr�c�dent et �ventuellement � l'ann�e pr�c�dente.

Apr�s y'a des moyens tr�s simples de faire ce genre d'op�rations.
Tu passes en timestamp unix et tu soustraies 3600*24.

**Jan Rendek** · 19/12/2006, 23h14

Je ne suis pas s�r que l'on comprenne la m�me chose.
Si je comprend correctement, l'OP � une date cod�e sur 8 octets dans l' JJMMAAAA.
Partant de l� il doit trouver la veille de cette date. Je ne vois pas vraiment l'utilit� d'un timestamp Unix ou autre. Ca se fait en deux ou trois ligne maxi.
Seulement donner la solution n'est pas la meilleur fa�on de l'aider je pense

**Luc Hermitte** · 20/12/2006, 01h52

(La date de l'OP aussi �trange soit-elle est directement comparable)

Sinon, je suis du m�me avis que loufoque => revenir � un type sur lequel on peut directement appliquer les op�rations arithm�tiques de bases que l'on est � m�me d'attendre de dates. Parce que l� il va gal�rer s'il reste avec �a et cela ne se fait d�finitivement pas en trois lignes (merci les bissextiles). Les 8 octets du double (ce n'est pas toujours 8 d'ailleurs) n'aident pas. Cela n'est pas au point du BCD ou de la chaine de caract�res. En revanche en quelques lexical_cast, strftime, strptime et quelques additions, c'est vite pli�, et vite robuste. Plus long � ex�cuter qu'une dizaines de if, divisions, et autres modulos, c'est s�r.

S'il s'agit d'un exo, ok pour le guider et lui montrer diverses approches.

Si c'est pour de la production, autant le diriger vers les solutions de production (� savoir d�j� ne pas utiliser des doubles formatt�s pour affichage

). Il y a des types standard qui bien que demandant un peu d'huile de coude offrent au moins un minimum viable. Des portables aussi (boost). Des li�s � une API (MFC/timestamps *nix/VCL/...).
Si qui n'emp�che pas de faire des exos � c�t� de ce qui finira en production. A propos d'exos, c'est un super classique d'ailleurs.

**Jan Rendek** · 20/12/2006, 02h42

Oui, on peut faire des choses tr�s complexes. Cependant la question est simple et la r�ponse devrait l'�tre aussi.
Oui un double c'est pas toujours 8 octets, m'enfin c'est 99,9% du temps le cas. De plus, si la date est cod�e JJMMAAAA c'est quand m�me plus que probable qu'on suppose que c'est bien 8 octets pour un double.
Enfin, prendre en compte les ann�es bissextiles rajoute un test et une d�claration de tableau suppl�mentaire.

Une fois n'est pas coutume, Luc, mais je trouve que ta r�ponse embrouillera le n�ophyte plus qu'il ne l'aidera.

**loufoque** · 20/12/2006, 02h52

De plus, si la date est cod�e JJMMAAAA

C'est l'inverse.

**ben_popcorn** · 20/12/2006, 10h03

Et non, ce n'est pas un exo, c'est bel et bien un cas mal g�r� dans une dll en production .....
en tout cas merci de votre aide, je vais voir ce que je peux faire avec tout �a

je vous tiens au jus
Ben

**Jan Rendek** · 20/12/2006, 14h44

mea culpa, si c'est pour de la prod Luc t'as fourni toute la panoplie

**ben_popcorn** · 20/12/2006, 16h20

bon j'ai opt� pour cette solution l�:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
/* arg est du type double au format AAAAMMJJ, ex: 20061220  */
double Veille(double arg)
{
	double ret = 0;
	int annee = (int)arg/10000;
	int mois = (int)((arg/100) - 100*annee);
	int jour = (int)(arg - 10000*annee - 100*mois);
	SYSTEMTIME madate;
	madate.wDay = jour;
	madate.wMonth = mois;
	madate.wYear = annee;
	FILETIME ft;
	SystemTimeToFileTime(&madate,&ft);
	double orig = ft.dwLowDateTime;
	ft.dwLowDateTime-=711573504;	// on passe au jour d'avant
	int r = 201;
	if(orig < ft.dwLowDateTime)
	{
		ft.dwLowDateTime+=2^31;
		ft.dwLowDateTime+=2^31;
		r = 202;
	}
	ft.dwHighDateTime-=r;
	FileTimeToSystemTime(&ft,&madate);
	return (double)(madate.wYear*10000+madate.wMonth*100+madate.wDay);
}

**Luc Hermitte** · 21/12/2006, 02h25

Envoy� par Jan Rendek

a- Oui, on peut faire des choses tr�s complexes. Cependant la question est simple et la r�ponse devrait l'�tre aussi.
b- Oui un double c'est pas toujours 8 octets, m'enfin c'est 99,9% du temps le cas. De plus, si la date est cod�e JJMMAAAA c'est quand m�me plus que probable qu'on suppose que c'est bien 8 octets pour un double.
c- Enfin, prendre en compte les ann�es bissextiles rajoute un test et une d�claration de tableau suppl�mentaire.

d- Une fois n'est pas coutume, Luc, mais je trouve que ta r�ponse embrouillera le n�ophyte plus qu'il ne l'aidera.

a- double -> string -> time_t -[addition]-> time_t -> string -> double
Chaque �tape de tranformation est tr�s simple et devrait �tre maitris�e par tout le monde. La compl�xit� algorithmique est nulle. Elle exige en revanche d'avoir les bases et de savoir lire une documentation de r�f�rence sur la biblioth�que standard pour en tirer des solutions ne souffrant pas du syndrome du NIH (Not invented Here).

On ne peut pas en dire autant de l'algo typique de l'exercice qui consiste � revenir � un nombre de jours �coul�s depuis une certaine date.

b-

Je ne vois pas le rapport avec un double dont la repr�sentation d�cimale textuelle donne "JJMMAAAA" (ou "AAAAMMJJ" peu importe) et 8 octets. Les 8 octets ne sont manipulables que s'il passe par une chaine. Or il a un double. 255 (aka 0xff) ne se code pas sur 3 octets, pas plus que AAAMMJJ.hhmmssmss ne se code sur 18 octets. Ce sont deux nombres, et aucun chiffre de la repr�sentation textuelle d�cimale de ne �tre directement extrait depuis un octet de ces nombres.

Sans passer par des chaines, il faut faire des divisions comme il a fait.
NB: le modulo (-> %) est ton ami.

c- Pas si "simple". Il faut int�grer sur les valeurs d'un tableau pour l'ann�e courante plus faire d'autres manips pour int�grer sur diverses ann�es dont certaines sont bissextilles. Un grand classique. Mais deux algos qui prennent un peu de temps � recoder et � retester avec tous les cas particuliers qui peuvent se pr�senter.

d- Je ne donne pas la solution. Juste des pistes pour quelqu'un qui sait se servir de google/man. D'autant qu'il est impossible dans de tels cas de savoir s'il s'agit d'un exo ou d'un probl�me plus concret -- le fait qu'il s'agissent d'un double m'a fait �carter l'hyppoth�se exo pour un cas de production bizarrement con�u.

@ben_popcorn
- "711573504" utiliser de pareilles constantes magiques (i.e. sorties d'un chapeau) est une tr�s mauvaise id�e. Si ceci est le r�sultat d'une multiplication de choses humainement compr�hensibles (60, 24, ...) fait apparraitre ces nombres.
- M�me chose pour les 2 xor 31. Pourquoi xor ?. 2 puissance 31 se code 1<<31, mais je ne vois pas d'o� �a sort. Le '^' est l'op�rateur xor bit � bit.

**Jan Rendek** · 21/12/2006, 08h22

b- Je ne vois pas le rapport avec un double dont la repr�sentation d�cimale textuelle donne "JJMMAAAA" (ou "AAAAMMJJ" peu importe) et 8 octets. Les 8 octets ne sont manipulables que s'il passe par une chaine. Or il a un double. 255 (aka 0xff) ne se code pas sur 3 octets, pas plus que AAAMMJJ.hhmmssmss ne se code sur 18 octets. Ce sont deux nombres, et aucun chiffre de la repr�sentation textuelle d�cimale de ne �tre directement extrait depuis un octet de ces nombres.

Ca d�pend comment on interpr�te les information � la base. Pour moi la date �tat 'cod�e' sur 8 octet stock�e dans un double (i.e. les 2 premiers octets repr�sentant le jour, etc.). Mon interpr�tation �tait peut-�tre �trange, mais pas plus que de stocker un entier � 8 chiffres repr�sentant la date dans un double.

c-(...)le fait qu'il s'agisse d'un double m'a fait �carter l'hypoth�se exo pour un cas de production bizarrement con�u.

Le fait qu'il s'agisse d'un double m'a fait moi pench� pour le cas d'un exo tordu.

**ben_popcorn** · 21/12/2006, 09h52

Envoy� par Luc Hermitte

@ben_popcorn
- "711573504" utiliser de pareilles constantes magiques (i.e. sorties d'un chapeau) est une tr�s mauvaise id�e. Si ceci est le r�sultat d'une multiplication de choses humainement compr�hensibles (60, 24, ...) fait apparraitre ces nombres.
- M�me chose pour les 2 xor 31. Pourquoi xor ?. 2 puissance 31 se code 1<<31, mais je ne vois pas d'o� �a sort. Le '^' est l'op�rateur xor bit � bit.

ok, merci des remarques Luc. Effectivement grosse boulette pour l'op�rateur de puissance ....shame on me .......

**ben_popcorn** · 21/12/2006, 09h59

c'est mieux comme �a ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
		ft.dwLowDateTime = ft.dwLowDateTime + (1<<31);
		ft.dwLowDateTime = ft.dwLowDateTime + (1<<31);

**Luc Hermitte** · 21/12/2006, 19h08

"mieux" ? Cela a beau correspondre � ce que tu sembles vouloir faire, je ne vois pas du tout d'o� �a sort et � quoi �a sert de faire des trucs aussi compliqu�s.

[VC++6]Conversion de date

Visual C++

Discussions similaires

Partager

Partager