Discussion :

[MaitrePylos]

Bonjour,
Nous utilisons une application qui repose sur Firebird.
Lorsque je veux faire des requêtes SQL, je sui confronté à un format de date que je ne connais pas.

voici ce que j'ai pour une date :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1.181.001

, je ne vois pas comment transformer cette date.
Merci de votre aide.

[Artemus24]

Salut MaitrePylos.

D'où sortez-vous ce format de date ? La date est-elle associée à un pays en particulier ?

Le 181 me semble être le nombre de jours dans l'année.
Impossible de savoir à quoi correspond le reste.

@+

[MaitrePylos]

Bonjour, je la sort directement de la db

C'est en fait un entier sur 8 position.

Donc le bon format serait 1181001

[SergioMaster]

Bonjour,

1.081.001 ça doit être parce que affiché avec séparateur de millier

La date 0 avec Firebird ou Interbase c'est normalement le 30/12/1899 un bug ODBC pourrait fournir 17/11/1898 mais cela importe peu à ce stade !

(les dates des casts sont fournies sous le format mm/jj/aaaa mais on peut utliser d'autres formats jj.mm.aaaa
car
select DATEADD(1181001 DAY TO CAST('11/17/1898' AS DATE)) from rdb$database -> 08.05.5132
select DATEADD(1181001 DAY TO CAST('30.12.1899' AS DATE)) from rdb$database -> 20.06.5133
AMHA c'est pas ça ou du moins n'est-ce pas en nombre de jours

DATEADD(1181001 HOUR TO CAST('30.12.1899' AS DATE)) pourrait peut-être convenir

comment est défini la colonne dans la table ?

[MaitrePylos]

C'est définit en tant que int(8) ou int(12), au niveau des dates c'est assez incohérents

[SergioMaster]

AMHA il s'agit d'une colonne traitée via l'application
Peut-on avoir le résultat de la requête ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM RDB$RELATION_FIELD WHERE  RDB$RELATION_NAME='nom_de_la_table'

parce que int(8) ou int(12) ça fait pas partie de mes types connus le plus petit SMALLINT : 16 bits, BIGINT en 32bits
à moins que nous ayons à faire à une table externe

Comment avez vous défini qu'il s'agissait d'une date ?

[MaitrePylos]

Bonjour,
je ne vous met que la ligne incriminé et les champs qui ont une valeur.

Et à quoi je pense que c'est une Date....au nom du champ.

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
 
RDB$FIELD_NAME
DATEVALIDCI                    
 
 
RDB$RELATION_NAME
ETUD                           
 
RDB$FIELD_SOURCE
RDB$231                        
 
RDB$FIELD_POSITION
25
 
RDB$UPDATE_FLAG	
1	
 
RDB$FIELD_ID
23

Merci de votre aide.

[Artemus24]

Salut à tous.

Je n'ai pas du tout pensé au séparateur des milliers, mais à un format de représentation.
Désolé pour cette mauvaise interprétation de ma part.

L'idée de ce nombre entier, suggérée par SergioMaster, représente un déplacement dans une unité qu'il faut identifiée, par rapport à une date pivot.
J'ai pensé dans un premier temps, que cette date pivot était soit '1970-01-01' ou soit '0001-01-01'. SergioMaster aux dates '1899-12-31' et '1898-11-17'.

J'ai pris la date pivot '0001-01-01', auquelle j'ai ajouté ce nombre de jours, et j'ai obtenu une date trop grande.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
select DATEADD(1181001 DAY TO CAST('0001-01-01' AS DATE)) from rdb$database;
 
    DATEADD
===========
3234-06-22

Cela suggère que cet entier n'exprime pas un nombre de jours !

J'ai pensé ensuite à des heures. Pourquoi pas ? J'ai pris comme date pivot '1899-21-31', ce qui donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
select DATEADD(1181001 hour TO CAST('1899-12-31' AS DATE)) from rdb$database;
 
    DATEADD
===========
2034-09-22

La date semble correcte, encore fait-il savoir si cela exprime quelque chose de cohérent.

J'ai repris le calcul afin de trouver le timestamp exacte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
select DATEADD(1181001 hour TO CAST('1899-12-31' AS timestamp)) from rdb$database;
 
                  DATEADD
=========================
2034-09-22 09:00:00.0000

Je ne sais pas trop quoi pensé de ce nouveau résultat.

Et si c'était des minutes ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
select DATEADD(1181001 minute TO CAST('1970-01-01' AS timestamp)) from rdb$database;
 
                  DATEADD
=========================
1972-03-31 03:21:00.0000

Il semble que cela ne soit pas la bonne date pivot ou la bonne unité.

J'arrive à la conclusion que l'idée première d'une date pivot et d'un déplacement en nombre de jours ne pouvait pas être la solution.

Je me suis dit que je m'y prenais mal et que je devais faire référence à la documentation pour savoir comment FirBird stocke les dates.
--> https://www.firebirdsql.org/en/firebird-date-literals/

En lisant la documentation, je me suis rappelé quand j'ai fait le passage à l'an 2000, que l'on codifiait les siècles du genre "0" pour 1900 et "1" pour 2000.
Avec cette astuce, on gagnant de la place dans le stockage des dates avec le type integer.

Du coup, les deux chiffres suivants doivent exprimer l'année.
Ça tombe bien, j'ai '18' qui va exprimer '2018'.
Les deux suivants le mois, et les deux derniers, les jours.
Si l'on met un séparateur pour exprimer la lisibilité de ce nombre entier, nous avons '1.18.10.01' qui va se lire '2018-10-01'.
Là, cela me semble beaucoup plus logique comme date, non ?

Voilà toute l'importance de bien documenter les applications et non de faire appel aux anciens pour des astuces d'un autre age.

@+

[MaitrePylos]

Mais qui à dit que vous veniez d'un autre age.
Alors je suis assez d'accord sur la doc, mais j'ai du mal à faire entendre raison aujourd'hui, j'imagine même pas les chef de projets il y a 20 ans.

Donc dans ma db 0 n'existe pas mais j'ai ceci : 960.829 donc c'est cohérents
le 1 on est d'accord c'est pour 2000 , mais , car il y a un mais, j'ai aussi ce format : 2.200.823 , du coup je me posais la question de savoir s'il y avais une différence entre le 00 et 20, ce qui expliquerais le 1 et 2 .

Je m'explique, je pense que ces deux dates sont équivalente :

1.000.906 = 2000-09-06
2.200.906 = 2000-09-06

Pensez-vous que mon raisonnement soit correcte ?

Merci.

[Artemus24]

Salut MaitrePylos.

Mais qui à dit que vous veniez d'un autre age.

C'est moi qui le dit.

Donc dans ma db 0 n'existe pas mais j'ai ceci : 960.829 donc c'est cohérents

Que je traduis par '0.96.08.29' ce qui donne '1996-08-29'.

Pour 0, je pourrais traduire cela par '1900-00-00' qui en réalité correspond à '1899-12-31'.

le 1 on est d'accord c'est pour 2000 , mais , car il y a un mais, j'ai aussi ce format : 2.200.823

J'interprète '2.20.08.23' par '2120-08-23' si l'on garde la même logique.
que signifie cette date '2120-08-23' dans votre application ?
N'est-elle pas un peu trop grande ?
Sort-elle des limites de votre traitement ?

du coup je me posais la question de savoir s'il y avais une différence entre le 00 et 20, ce qui expliquerais le 1 et 2.

Quel '00' et quel '20' ? Je ne comprends pas.

Pensez-vous que mon raisonnement soit correcte ?

Il suffit de prendre comme année pivot '1900'.
Vous interprétez l'année comme un entier à laquelle vous retranchez l'année pivot.
Ce qui donne 2018 - 1900 = 118.

Ou encore 20181001 - 19000000 = 1181001

En pratiquant le raisonnement de l'année pivot '1900', on trouve :
--> 0 pour 1900
--> 1 pour 2000
--> 2 pour 2100
--> 3 pour 2200

Bien que cela soit une astuce, je pense quelle n'a aucune raison d'être dans un integer, puisque nous pouvons stocker la date comme un nombre entier.
Un integer est sur 4 octets et peut stocker un nombre allant de -2.147.483.648 (2^31) jusqu'à +2.147.483.647 (2^31-1).
Ce qui donne pour cette date '9999-12-31', le nombre entier +99.991.231 < 2.147.483.647

On peut se poser une autre question, à savoir le sens de lecture de la date.

@+

[MaitrePylos]

Soyez assuré que la sagesse vient de m'éviter un Burnout lattent

J'interprète '2.20.08.23' par '2120-08-23' si l'on garde la même logique.
que signifie cette date '2120-08-23' dans votre application ?
N'est-elle pas un peu trop grande ?
Sort-elle des limites de votre traitement ?

Cette date effectivement est incohérente, je recherche à quoi elle peux correspondre.

[QUOTE:Artemus]
Quel '00' et quel '20' ? Je ne comprends pas.
[/QUOTE]

Je prenais l'exemple des deux date suivantes :

1.000.906 = 2000-09-06
2.200.906 = 2000-09-06

Je me disais que
1 = 00 pour l'an 2000
2 = 20 pour l'an 2000

Comme cette base de données, n'est absolument pas normalisé, j'essayais de penser autrement
En tout cas un grand merci....me voila remis d'aplomb pour corriger un certains nombres de requêtes.

[Artemus24]

Salut MaitrePylos.

Lors du passage à l'an 2000, nous avions aussi une autre façon d'écrire nos dates.
Si le format de la date était 'YY/MM/DD', pour calculer les siècles, nous prenions comme date pivot '1970'.
Et nous appliquions la règle suivante :
--> Si YY >= 70 alors siècle = 19.
--> si yy < 70 alors siècle = 20.
Nous avions alors plus qu'à ajouter le siècle à la date sur six chiffres !

Pourquoi '1970' ? Parce que nous n'avions aucune date inférieur à ce nombre.
D'ailleurs, nous retrouvons cette date pivot dans Unix et le stockage sous forme numérique de la date.

A moins de me tromper, en cas de doute, vous pouvez juste interpréter l'année, sans tenir compte de ce premier chiffre.
Pour ce faire, il suffit juste de regarder l'année. Votre date '2.20.08.23' pourrait s'interpréter de la façon suivante :
l'année étant égale à '20' et celle-ci étant inférieure à '70', nous sommes alors au 20 ième siècle.
Dans le cas contraire, le siècle, c'est '19'. Et le format devient : 2020-08-23'.

@+