IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

SQLite Discussion :

Affichage de date


Sujet :

SQLite

  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    491
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 491
    Par défaut Affichage de date
    Bonjour,

    via SQL, J'insère une date dans une table de ma base, dans un champ DATE

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    INSERT INTO matable (ident, valide, creation_date) VALUES ("IA1.01.02", False, 40868.66688657407);
    40868.66688657407 correspond au 21/11/2011 16:00:19

    Quand je veux afficher ma date avec un SELECT:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT creation_date, strftime('%d/%m/%Y %H:%M:%S',creation_date) as ptime FROM matable
    ça me renvoie 17/10/-460 04:00:19

    Qu'est ce qui cloche?

    Merci,
    Nico

  2. #2
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 586
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 69
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 586
    Billets dans le blog
    65
    Par défaut
    Bonjour,

    Qu'est ce qui cloche?
    moi, j'écrirais votre manière de faire l'insert, je ne sais pas où vous avez été pêcher votre valeur 40868.66688657407
    en tout cas j'apprend une chose, SQLite peut utiliser des dates J-C ! Reste à trouver le bon calcul mais je ne m'y fierai pas

    j'écrirais
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    INSERT INTO matable (ident, valide, creation_date) VALUES ("IA1.01.02", False, '2011-11-21 16:00:19');

    EDIT si vous voulez entrer des valeurs numeriques utilisez des choses comme 'unixepoch'
    ici un calcul de démo
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT (julianday('2011-11-21') - 2440587.5)*86400.0,datetime(1321833600+57619, 'unixepoch'),1321833600+57619
    la valeur s'il devait y en avoir une pour '2011-11-21 16:00:19' serait 2455887.166886574
    obtenue ainsi
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT strftime('%J','2011-11-21 16:00:19')
    %J pour juliandate

  3. #3
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2005
    Messages
    491
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2005
    Messages : 491
    Par défaut
    OK ça marche !

    je ne sais pas où vous avez été pêcher votre valeur 40868.66688657407
    via un script Python, je lit mes données directement dans un fichier Excel et je génère un fichier sql qui contient mes commandes INSERT. Les valeurs 'bizarre' de date viennent d'une cellule Excel contenant une date, mais du coup, en lisant aussi le formatage de la cellule, je peut reconstituer une chaine correcte correspondant à une date compatible avec le INSERT sql

    Nico

  4. #4
    Membre prolifique Avatar de Jon Shannow
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    Avril 2011
    Messages
    4 726
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Avril 2011
    Messages : 4 726
    Par défaut
    Bonjour,

    Le problème des dates en numérique, c'est que tous les logiciels ne prennent pas la même date de référence. Du coup, une valeur dans un logiciel ne correspond pas forcément à la même date dans un autre logiciel. C'est pour cela qu'il est plus intéressant et plus fiable de stocker les dates sous forme de chaines au format AAAAMMJJ et les "DateHeure" sous le format AAAAMMJJhhmmss et "ccc" ou "mmmm" selon le besoin

    JS

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 997
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 997
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par Jon Shannow Voir le message
    Bonjour,

    Le problème des dates en numérique, c'est que tous les logiciels ne prennent pas la même date de référence. Du coup, une valeur dans un logiciel ne correspond pas forcément à la même date dans un autre logiciel. C'est pour cela qu'il est plus intéressant et plus fiable de stocker les dates sous forme de chaines au format AAAAMMJJ et les "DateHeure" sous le format AAAAMMJJhhmmss et "ccc" ou "mmmm" selon le besoin

    JS
    Ta réponse est hautement stupide. Le type DATE en SQL est une norme datant de 1986 et est utilisé par tous les SGBDR et n'a jamais causé aucun problème d'interprétation. En revanche c'est parfaitement imbécile d'utiliser le UNIX TIMESTAMP qui n'a rien à voir avec une date !
    https://fr.wikipedia.org/wiki/Heure_Unix

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #6
    Membre prolifique Avatar de Jon Shannow
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    Avril 2011
    Messages
    4 726
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Avril 2011
    Messages : 4 726
    Par défaut
    Merci pour le compliment, mais je ne parlais pas forcément des SGBDR, mais de la gestion des dates dans les différents langages et de leur inter-compatibilités. Si je doit gérer des dates provenant de plusieurs univers, je vais les gérer au format chaine, comme dit précédemment, pour être sûr d'avoir toujours le même format.
    C'est tout.

  7. #7
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 586
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 69
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 586
    Billets dans le blog
    65
    Par défaut
    Disons que SQLpro est toujours aussi diplomate
    Pour ce qui est de l'imbécilité d'utiliser un unix timestamp, bien que cela dépende un peu de l'OS, je m'aperçois avoir oublié un petit bout de phrase dans mon texte de réponse : "ou le temps Julien"

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 997
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 997
    Billets dans le blog
    6
    Par défaut
    Unixtimestamp n'est pas une date et le confondre avec une date est une imbécilité qui fausse de nombreux calcul.
    unixtimestamp est une durée. Ce n'est pas la même chose !

    Pour ton information une date est un point dans le temps.
    Une durée est une quantité de temps.

    Révise les maths !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Réponses: 3
    Dernier message: 30/05/2006, 21h28
  2. Affichage de date
    Par dotiaman dans le forum Bases de données
    Réponses: 1
    Dernier message: 12/01/2006, 21h08
  3. problème d'affichage de date
    Par Commodore dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 2
    Dernier message: 07/12/2005, 08h50
  4. cocher une case+affichage de dates
    Par Toff !!!!! dans le forum Access
    Réponses: 2
    Dernier message: 17/10/2005, 10h07
  5. Probleme avec affichage de date
    Par Wongmaster dans le forum Access
    Réponses: 27
    Dernier message: 24/12/2004, 20h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo