Type as DATE
sygale
Messages postés
24
Date d'inscription
mardi 19 mars 2002
Statut
Membre
Dernière intervention
19 mai 2003
-
12 mai 2003 à 14:03
cs_Base Messages postés 70 Date d'inscription jeudi 23 janvier 2003 Statut Membre Dernière intervention 31 juillet 2003 - 12 mai 2003 à 18:48
cs_Base Messages postés 70 Date d'inscription jeudi 23 janvier 2003 Statut Membre Dernière intervention 31 juillet 2003 - 12 mai 2003 à 18:48
5 réponses
cs_moustachu
Messages postés
1079
Date d'inscription
jeudi 14 novembre 2002
Statut
Membre
Dernière intervention
1 janvier 2012
12 mai 2003 à 14:11
12 mai 2003 à 14:11
Ben si tu le formate à deux chiffres pour l'année puis ensuite quatre, il doit "deviner" quels sont les deux premiers chiffres. C'est le bug de l'an trois mille c'est tout.
cs_Base
Messages postés
70
Date d'inscription
jeudi 23 janvier 2003
Statut
Membre
Dernière intervention
31 juillet 2003
12 mai 2003 à 14:33
12 mai 2003 à 14:33
Whaaaaaa...
C pas banal ça !!! Imagines le travail demandé au complilateur VB !!! J'espère que le reste du source n'est pas aussi , heuuu... Comment dirais-je.... si peu optimisée... Quel est le but de la manip au juste ???
B@se 8-)
C pas banal ça !!! Imagines le travail demandé au complilateur VB !!! J'espère que le reste du source n'est pas aussi , heuuu... Comment dirais-je.... si peu optimisée... Quel est le but de la manip au juste ???
B@se 8-)
sygale
Messages postés
24
Date d'inscription
mardi 19 mars 2002
Statut
Membre
Dernière intervention
19 mai 2003
12 mai 2003 à 14:55
12 mai 2003 à 14:55
Le but de la manipulation est de récupérer des dates affichées dans des flexgrids pour l'instant au format DD/MM/YY (gain de place très grand flex). cependant lors de l'utilisation de cdate on s'apercoit que l'anée sur deux caractère s'arrête à 2029.
test
format$(cdate("31/12/29"),"DD/MM/YYYY") = 31/12/2029
format$(cdate("31/12/30"),"DD/MM/YYYY") = 31/12/1930
donc je suis dans l'obligation de traiter mes date sur le format DD/MM/YYYY sinon le siècle peut être erronné (pour ma part).
Bug du troisième millénaire on m'a dit :
http://www.vbfrance.com/forum.aspx?Article=64752
Enfin le problème est le même quelque soit les paramètres régionaux.
Après réflexion je trouve ca normal si dans une string tu n'a pas la valeur du siècle il faut bien prendre une valeur par défaut !!
Dommage que la flexgrid ne soit alimentée que par des types string et pas date, time, integer, long... enfin faut pas trop en demander
Et pour finir, le bout de code donné en exemple est une copie de la feuille d'éxécution (CTRL + G) dans VB, pour l'optimisation ne t'inquête pas !!
Il y a 400 millions d'obtenir un résultat en programation, il faut cependant choisir le plus adapté à ton application, et c'est ca le boulot d'un dev !!
un 486 avec 1Go de mémoire vive ca rame !!!!!
Merci quand même pour la rapidité de ta réponse et ta proposition d'aide. :)
Sygale
sygale@ifrance.com
test
format$(cdate("31/12/29"),"DD/MM/YYYY") = 31/12/2029
format$(cdate("31/12/30"),"DD/MM/YYYY") = 31/12/1930
donc je suis dans l'obligation de traiter mes date sur le format DD/MM/YYYY sinon le siècle peut être erronné (pour ma part).
Bug du troisième millénaire on m'a dit :
http://www.vbfrance.com/forum.aspx?Article=64752
Enfin le problème est le même quelque soit les paramètres régionaux.
Après réflexion je trouve ca normal si dans une string tu n'a pas la valeur du siècle il faut bien prendre une valeur par défaut !!
Dommage que la flexgrid ne soit alimentée que par des types string et pas date, time, integer, long... enfin faut pas trop en demander
Et pour finir, le bout de code donné en exemple est une copie de la feuille d'éxécution (CTRL + G) dans VB, pour l'optimisation ne t'inquête pas !!
Il y a 400 millions d'obtenir un résultat en programation, il faut cependant choisir le plus adapté à ton application, et c'est ca le boulot d'un dev !!
un 486 avec 1Go de mémoire vive ca rame !!!!!
Merci quand même pour la rapidité de ta réponse et ta proposition d'aide. :)
Sygale
sygale@ifrance.com
cs_moustachu
Messages postés
1079
Date d'inscription
jeudi 14 novembre 2002
Statut
Membre
Dernière intervention
1 janvier 2012
12 mai 2003 à 16:27
12 mai 2003 à 16:27
Hé j'espère que tu n'as pas mal pris mes commentaires...
J'ai eu des problèmes "autrefois" pour un truc comme le tiens.
Je l'avais résolu en passant par un tableau qui contenait les valeurs en variant de ce qu'on voulait mettre dans la grille, ensuite on parcourrait le tableau pour alimenter la grille.
C'est pas top niveau optmisation mais ça nous a dépanné
++
Moustachu
J'ai eu des problèmes "autrefois" pour un truc comme le tiens.
Je l'avais résolu en passant par un tableau qui contenait les valeurs en variant de ce qu'on voulait mettre dans la grille, ensuite on parcourrait le tableau pour alimenter la grille.
C'est pas top niveau optmisation mais ça nous a dépanné
++
Moustachu
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
cs_Base
Messages postés
70
Date d'inscription
jeudi 23 janvier 2003
Statut
Membre
Dernière intervention
31 juillet 2003
12 mai 2003 à 18:48
12 mai 2003 à 18:48
:) Je comprend mieux... J'espère que mon intervention ne t'a pas trop vexé, mais ta syntaxe était impressionnante....
J'ai également rencontré le problème... Les calendriers microsoft s'arrètent souvent en 2030... (ils aiment les patchs et surtout vendre de nouveau produits...)
Effectivement si le siècle n'est pas précisé, la convertion sur 4 digits se fera sur celui en cours jusqu'en 2030 (non inclu). Autrement il considère que c'est 19..
La logique veut que si l'on code les années sur 2 digits c'est que ce sont des dates courantes et comme la micro n'est généralisée que depuis 20 ans, le problème ne se pose pas tant que tes conversions seront faites avant 2029...
Mais je te l'accorde, il y a tjrs le cas particulier qui confirme la règle... Enfin tous ça pour te dire que lorsqu'on écrit une routine de convertion il faut souvent interpréter les besoins et, malheureusement, émètres des hypotèses, comme : Est-ce que ma fiche peut intégrer des dates en dessous des annèes 1980 ou au dessus de 2003, au moment de la convertion... Enfin tu vois ce que je veux dire...
B@se 8-)
J'ai également rencontré le problème... Les calendriers microsoft s'arrètent souvent en 2030... (ils aiment les patchs et surtout vendre de nouveau produits...)
Effectivement si le siècle n'est pas précisé, la convertion sur 4 digits se fera sur celui en cours jusqu'en 2030 (non inclu). Autrement il considère que c'est 19..
La logique veut que si l'on code les années sur 2 digits c'est que ce sont des dates courantes et comme la micro n'est généralisée que depuis 20 ans, le problème ne se pose pas tant que tes conversions seront faites avant 2029...
Mais je te l'accorde, il y a tjrs le cas particulier qui confirme la règle... Enfin tous ça pour te dire que lorsqu'on écrit une routine de convertion il faut souvent interpréter les besoins et, malheureusement, émètres des hypotèses, comme : Est-ce que ma fiche peut intégrer des dates en dessous des annèes 1980 ou au dessus de 2003, au moment de la convertion... Enfin tu vois ce que je veux dire...
B@se 8-)