L'heure qui ne voulait pas être une heure

J’ai un formulaire dans lequel j’ai diverses zones, dont des dates et heures début/fin, comme ça :
Form.dateDebut * type de variable = date
Form.dateFin * type de variable = date
Form.heureDebut * type de variable = heure
Form.heureFin * type de variable = heure
Le type de variable choisi détermine automatiquement la liste des formats d’affichage possibles pour le type, date ou heure, logique.

Au chargement du formulaire, j’affecte des valeurs date et heure à ces 4 champs. Résultat, les dates sont bien des dates, mais 4D voit obstinément les heures comme des longs : 21600 pour 6:00 et 57600 pour 18:00.

Quel gri-gri cosmique faut-il invoquer pour lui faire entendre qu’une heure est une heure ?

Je précise :

  • j’ai bien une heure lorsque j’utilise une variable “classique” ou dynamique
  • 4D v17r4

C’est Form.toutSaufUneHeure ?

Peut être bien parce que pour les objets une valeur de propriété ne
peut pas être du type heure.

: Documentation

Une valeur de propriété peut être du type suivant :
nombre (réel, entier long, etc.)
texte
tableau (texte, réel, booléen, objet, pointeur)
null
booléen
pointeur (stocké tel quel, évalué à l’aide de la commande JSON
Stringify ou lors d’une copie),
date (type date ou chaîne au format date ISO - voir Page
Compatibilité, option “Utiliser le type date au lieu du format date
ISO dans les objets”)
objet (les objets peuvent être imbriqués sur plusieurs niveaux)
image(*)
collection

https://doc.4d.com/4Dv17R6/4D/17-R6/Types-de-donnees.300-4311472.fe.html#3368035

Je m’y suis déjà frotté :sunglasses:

La page ‘Compatibilité’ des propriétés de la base spécifie :

Utiliser le type date au lieu du format date ISO dans les objets :
vous permet de stocker les dates dans les attributs d’objets avec le
type date plutôt qu’en texte au format ISO. Dans les versions
précédentes de 4D, les dates dans les attributs d’objets pouvaient
uniquement être stockées sous forme de chaîne de caractères. A
compter de 4D v16 R6, les dates dans les attributs d’objets peuvent
être stockées avec le type date. Vous pouvez activer ce
fonctionnement en cochant cette option (les dates précédemment
stockées au format texte ISO ne seront pas modifiées, mais les
nouvelles dates seront stockées avec le type date). Ce paramètre peut
également être géré par programmation pour chaque process à l’aide de
la commande SET DATABASE PARAMETER et du sélecteur Dates inside
objects.

Quel est le choix par défaut de 4D ?
Quel est le choix qui prépare le mieux le futur ?
Je suppose que c’est la format ISO…
J’espère que c’est la même réponse pour les deux questions !

: Bernard ESCAICH

Quel est le choix par défaut de 4D ?
Cette question renvoie à une remarque faite plusieurs fois par Arnaud : il faudrait que tous les réglages de compatibilité soient dans le même sens, cochés pour le nouveau choix.

En effet, j’avais affronté le problème avant la v16R6 et opté pour une
utilisation de la date sous forme de chaine.

: Bernard ESCAICH

Quel est le choix par défaut de 4D ?
Je viens de regarder (v17R6) et la case de comptabilité est cochée. Je ne me souviens pas de l’avoir cochée, mais je n’y mettrais pas ma tête à couper :mrgreen:

: Bernard ESCAICH

Quel est le choix qui prépare le mieux le futur ?
Je suppose que c’est la format ISO…
C’est aussi mon avis.

Meilleurs vœux à tous.

Bonjour

Pour les heures, la réponse a été donnée je pense (cf la doc)

Pour les dates ça dépend s’il s’agit d’une base convertie ou non.

Si c’est une base convertie, par défaut ça reste “comme avant” à savoir format ISO (donc texte)
… et on peut décider d’utiliser le format date plutôt que texte

Si c’est une base nouvelle, alors l’option de compatibilité disparait (c’est habituel dans les nouvelles bases) et le format par défaut c’est date. Si on veut absolument stocker en ISO, il y a un SET DATABASE PARAMETER pour ça. (voir valeur 85 : Dates inside objects)

Roland

Merci pour vos réponses. Bon, si je comprends bien, il est « normal » de ne pouvoir proposer une saisie d’heure via un Form.quelqueChose avec 4D. Même si c’est documenté et qu’il n’est pas très compliqué de tourner autour, ça me fait bizarre de devoir traiter l’heure comme un exception avec Form.

Une bonne année à tous !

A partir de cette année, le format des dates est ‘date’, il n’y a pas d’heure : j’avoue ne pas comprendre…
Si on veut stocker des heures ou des dates/heures, il faut transformer en format ISO, stringifier (ah l’élégant néologisme) et vice-versa, ou traiter séparément les dates et un entier long pour les heures ?
On simplifie pour les dates mais pas pour les heures !
Le champ timestamp existe pourtant en SQL…

J’aimerais pouvoir traiter les dates/heures dans un seul champ/variable/propriété acceptant un Timestamp avec :

  • une fonction AJOUTER A DATE(maDate;NbAnnées;NbMois;NbJours;NbHeures;NbMinutes;NbSecondes;NbMillisecondes)
  • les fonctions manipulant dates et heures adaptées.
    C’est un fantasme de ma part ou d’autres ont le même besoin ?

Je me contente pour le moment de timestamps en entier long. Ça limite la période traitée, mais pour des données de gestion ça suffit et un entier long n’est pas mal en termes de performances. Le https://doc.4d.com/4Dv17R6/4D/17-R6/Implementations-du-moteur-SQL-de-4D.300-4463838.fr.htmltimestamp> finira bien par sortir du bois SQL…

: Bernard ESCAICH

Cette question renvoie à une remarque faite plusieurs fois par Arnaud
: il faudrait que tous les réglages de compatibilité soient dans le
même sens, cochés pour le nouveau choix.
Il est vrai que c’est le genre de choses qui ont le don de m’énerver, mais https://forums.4d.com/Post/FR/26627543/1/26627544#26627544pas que moi> :wink:

Eh, tu commences mal l’année si tu t’énerves !

“Je fais quoi de mon couteau, hein ?”
[]33208613;“Your comment here…”[/]

Des couteaux comme ça j’aime bien…
Bonne année à tous et 6 R-releases afin de tout réécrire dans vos bases,…
Happy new year