[VC++6]Conversion de date

Version imprimable

19/12/2006, 14h13
ben_popcorn

[VC++6]Conversion de date

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
19/12/2006, 14h20
Jan Rendek

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
19/12/2006, 15h29
Feriaman

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.
19/12/2006, 22h58
loufoque

Citation:

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.
19/12/2006, 23h14
Jan Rendek

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
20/12/2006, 01h52
Luc Hermitte

(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.
20/12/2006, 02h42
Jan Rendek

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.
20/12/2006, 02h52
loufoque

Citation:

De plus, si la date est codée JJMMAAAA

C'est l'inverse.
20/12/2006, 10h03
ben_popcorn

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
20/12/2006, 14h44
Jan Rendek

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

bon j'ai opté pour cette solution là:

Code:

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);
}

21/12/2006, 02h25
Luc Hermitte

Citation:

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- 8O 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.
21/12/2006, 08h22
Jan Rendek

Citation:

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.

Citation:

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.
21/12/2006, 09h52
ben_popcorn

Citation:

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 .......:oops:

c'est mieux comme ça ?

Code:

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

21/12/2006, 19h08
Luc Hermitte

"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.