Gambas France BETA


Pas de compte ? Incription

Champ date mysql

1
AuteurMessages
Jack#1 Posté le 29/8/2017 à 16:33:18
bonjour,

avec la version 3.10 de gambas voilà le résultat d'une requête mysql sur un champ date.
06/30/2017 02:00:00
Avant j'avais 06/30/2017
Je précise qu'il s'agit bien d'un champ date et non datetime et que phpmyadmin affiche bien 06/30/2017
Quelqu'un a-t-il noté ce problème ?
Comment apporter une solution ?
Pour un code démocratique nationalisons Gambas.
Jack#2 Posté le 29/8/2017 à 19:12:14
J'ai résolu mon problème en formatant le résultat de la requête mais je ne crois pas que ce soit très orthodoxe comme manière de faire.
Pour un code démocratique nationalisons Gambas.
davidmue#3 Posté le 30/8/2017 à 22:22:39
Salut, j'ai vu le problème car je m'essaie aux applications Gambas / MySQL ces derniers jours.
Pas certain que ça aide mais j'ai remarqué qu'en utilisant
date_event TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
ou
$connection.MySQL.Field.Add("date_event", $connection.MySQL.DataTypes.TimeStamp, False, "CURRENT_TIMESTAMP",, "CURRENT_TIMESTAMP")
ça fonctionne.
Bonne soirée.
David
Gambas.. C'est chouette !
Jack#4 Posté le 31/8/2017 à 09:22:58
Bonjour Davidmue,

merci pour ta réponse, cependant, et peut-être me suis-je mal exprimé, le problème ne vient pas de Mysql mais de Gambas.
Le retour fourni par Mysql est bon (06/30/2017) puisque le champ est de type date.
C'est Gambas qui devrait normalement fournir une donnée Date alors qu'il fournit une donnée Datetime.
Avec les versions antérieures ce problème n'existait pas.
Pour un code démocratique nationalisons Gambas.
jeanyvon#5 Posté le 31/8/2017 à 10:44:29
Gambas? Ma! Et gustoHello!
Pour un spinbox j'avais besoin d'un N° d'année j'avais donc:
1
mavariable = Right(CStr(Date),4)

avant mavariable = 2017
maintenant, mavariable = 0:00
j'ai donc fait
1
mavariable = Right(Left(CStr(Date),10),4)

Vieillir? On peut retarder mais pas y échapper!
Jack#6 Posté le 31/8/2017 à 22:38:47
Merci jeanyvon,

je ne comprends pas pourquoi cela a été changé. Ca me paraît être une anomalie.
Dans mysql il existe un type date bien différencié du datetime et avant la version 3.10, gambas retournait correctement la donnée en fonction du type.
Pour un code démocratique nationalisons Gambas.
davidmue#7 Posté le 31/8/2017 à 22:52:00
Salut Jack, je suis d'accord. C'est probablement un bogue. Gambas stocke les dates au format UTC et MySQL aussi. J'ai aussi constaté le problème avec le type Date et j'ai lu dans l'aide qu'il fallait préférer TIMESTAMP. Il faudrait fournir un code pour montrer le problème je pense. David

Gambas.. C'est chouette !
davidmue#8 Posté le 8/9/2017 à 06:20:42
Salut :)

C'est effectivement dans les changements depuis Gambas 3.10 : CStr et CDate convertissent tous les deux les valeurs à l'heure UTC en interne. As-tu annoncé le bogue ? Moi, je ne sais pas comment procéder.

Voici un code pour la conversion au cas où :

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
' Gambas module file

PUBLIC SUB Main()

DIM dLocal AS DATE
DIM dUtc AS DATE
DIM sDateUtcAConvertir AS STRING
DIM dateUtcAConvertir AS DATE
DIM dateLocaleConvertie AS DATE

PRINT "heure locale + " & CStr(((System.TimeZone / 60) / 60)) & " heure(s) == UTC !"
dLocal = Now

' calcul de la date UTC si on connait la date locale
dUtc = DateAdd(dLocal, gb.Second, CInt(System.TimeZone))

PRINT dLocal
PRINT dUtc

PRINT "Donnez la date UTC SVP! Par exemple 2017-08-29T12:00:00Z \n"
INPUT sDateUtcAConvertir
dateUtcAConvertir = GetDateFromIsoText(sDateUtcAConvertir)

' calcul de la date locale si on connait la date UTC
dateLocaleConvertie = DateAdd(dateUtcAConvertir, gb.Second, (0 - CInt(System.TimeZone)))

PRINT dateLocaleConvertie

END

FUNCTION GetDateFromIsoText(sIsoDate AS STRING, OPTIONAL bUTC AS BOOLEAN = FALSE) AS DATE

DIM dResult AS DATE
DIM sArray AS String[]

IF sIsoDate LIKE "*-*-*T*:*:*-*:00" THEN
sArray = Scan(sIsoDate, "*-*-*T*:*:*-*:00")
dResult = Date(sArray[0], sArray[1], sArray[2], sArray[3], sArray[4], sArray[5])
IF bUTC THEN
dResult = DateAdd(dResult, gb.Hour, CInt(sArray[6]))
ENDIF
ELSE IF sIsoDate LIKE "*-*-*T*:*:*+*:00" THEN
sArray = Scan(sIsoDate, "*-*-*T*:*:*+*:00")
dResult = Date(sArray[0], sArray[1], sArray[2], sArray[3], sArray[4], sArray[5])
IF bUTC THEN
dResult = DateAdd(dResult, gb.Hour, 0 - CInt(sArray[6]))
ENDIF
ELSE IF sIsoDate LIKE "*-*-*T*:*:*Z" THEN
sArray = Scan(sIsoDate, "*-*-*T*:*:*Z")
dResult = Date(sArray[0], sArray[1], sArray[2], sArray[3], sArray[4], sArray[5])
ELSE IF sIsoDate LIKE "*-*-* *:*:*" THEN
sArray = Scan(sIsoDate, "*-*-* *:*:*")
dResult = Date(sArray[0], sArray[1], sArray[2], sArray[3], sArray[4], sArray[5])
IF bUTC THEN
Error.Raise("Error. TimeZone not known. Cannot calculate! ")
ENDIF
ELSE IF sIsoDate LIKE "*-*-*" THEN
sArray = Scan(sIsoDate, "*-*-*")
IF IsInteger(sArray[0]) AND IsInteger(sArray[1]) AND IsInteger(sArray[2]) THEN
dResult = Date(sArray[0], sArray[1], sArray[2])
IF bUTC THEN
Error.Raise("Error. TimeZone not known. Cannot calculate! ")
ENDIF
ELSE
Error.Raise("Error. Unrecognized format (a)! Cannot Parse!")
ENDIF
ELSE
Error.Raise("Error. Unrecognized format (b)! Cannot Parse! ")
ENDIF
RETURN dResult

END



Gambas.. C'est chouette !
davidmue#9 Posté le 13/9/2017 à 22:07:37
Salut,
après avoir cherché, je n'ai pas pu reproduire le bogue.
Je pense qu'il est important de ne pas faire de conversion. Ne pas utiliser CDate(). Ne pas utiliser CStr(). Laissez la DateBox s'occuper de tout !
J'ai mis le code que j'ai utilisé pour tester sur la forge (TestDateTimeMySQL).

Pour l'extraction de l'année :
1
Format(DateBox1.Value, "yyyy")


A+

David
Gambas.. C'est chouette !
gambix#10 Posté le 1/10/2017 à 08:49:51
Faire simple !exacte ... même problème qu'avec Jean-Yvon... C'est un bogue qui a été résolu dans la 3.10 mais qui n'est pas rétro actif. Maintenant CDate agit en cohérence avec CStr.

Moins de texte dans une signature c'est agrandir son espace.
1