Ankündigung

Einklappen
Keine Ankündigung bisher.

Datumsformat Postgresql

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Datumsformat Postgresql

    Hallo zusammen,
    ich versuche mich gerade an einem Backend mit PHP und Postgresql als Datenbank.
    Nun stoße ich auf Probleme mit dem Datumsformat. Dies wird ja eigentlich im Format y-m-d abgespeichert (2019-04-30).
    Es wäre möglich die Datenbank in einer Conf-Datei auf dmy umzustellen. Das wird sich vermutlich auf die ganze Datenbank auswirken
    und da ich die Folgen nicht abschätzen.
    Ich habe mir auch schon überlegt den Unix Timestamp zuverwenden. Aber da muss ich in auf allen Seiten umwandeln.
    Wie geht ihr so mit dem Datumsformat um?


  • #2
    Was willst Du denn erreichen? Wenn Du die Ausgabe nach etwas formatiert haben willst, nutze einfach to_char:

    Code:
    test=*# select current_date;
        date    
    ------------
     2019-04-21
    (1 row)
    
    test=*# select to_char(current_date, 'dd.mm.yyyy');
      to_char   
    ------------
     21.04.2019
    (1 row)
    
    test=*#
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

    Kommentar


    • #3
      Danke für die schnelle Antwort.
      Es geht eigentlich in erster Linie um das Abspeichern.
      Die Auslieferung ist in der Regel nicht das Problem.
      Angeliefert wird in der Regel das Format d.m.y
      Nun stelle ich mir die Frage ob es sinnvoll ist die Datenbank umzustellen oder alles irgendwie zu parsen.
      Die meisten Frameworks arbeiten ja mit dem Format y-m-d.

      Ist es sinnvoll die DB auf d.m.y umzustellen oder kannst das evtl. unvorhergesehene Probleme auslösen?

      Kommentar


      • #4
        Du kannst das umstellen, kein Problem. Das geht sogar innerhalb einer Session.

        Code:
        test=*# set datestyle = 'DMY';
        SET
        test=*# select '21-04-2019'::date;
            date    
        ------------
         21/04/2019
        (1 row)
        
        test=*# set datestyle = 'ISO';
        SET
        test=*# select '21-04-2019'::date;
            date    
        ------------
         2019-04-21
        (1 row)
        
        test=*# set datestyle = 'GERMAN';
        SET
        test=*# select '21-04-2019'::date;
            date    
        ------------
         21.04.2019
        (1 row)
        
        test=*#
        Auf die intere Speicherung hat das keine Auswirkung, nur auf die Ausgabe bzw. auch Interpretation übergebener Datumswerte.
        PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

        Kommentar


        • #5
          Ich würde User-Interface-Themen im Frontend und nicht in der Datenbank lösen. Das ist meiner Ansicht nach der "saubere" Ansatz. Die Datenbank für die Datenhaltung und die Frontend-Anwendung für Ein-/Ausgabeformatierungen.

          Kommentar


          • #6
            Zitat von kaptainIglo Beitrag anzeigen
            Nun stelle ich mir die Frage ob es sinnvoll ist die Datenbank umzustellen oder alles irgendwie zu parsen.
            Die meisten Frameworks arbeiten ja mit dem Format y-m-d.

            Ist es sinnvoll die DB auf d.m.y umzustellen oder kannst das evtl. unvorhergesehene Probleme auslösen?
            Zeile1: Ich stelle doch nicht die DB um, weil jemand in dem Format Daten liefert. Was machst Du beim nächsten Lieferanten?
            Und was willst Du parsen? In "normalen" Systemen ist es gute Praxis, ein Format zu vereinbaren, zu erwarten und einzuhalten, alles andere ist dann ein Fehler.
            Du kannst das -wie schon gepostet wurde- mit DB Bordmitteln ganz bequem angeben und zwar jedes Mal, wenn Du ein externes Datum anfasst.
            Zeile2: Es geht bei der Softwareentwicklung nicht unbedingt demokratisch zu.
            Zeile3: Sinnvoll? Anhand der Infos nicht feststellbar.
            Kann es Unvorhergesehene Probleme auslösen? Diese Frage führt sich selbst ad absurdum. Sie muss mit Ja beantwortet werden.
            Selbst verallgemeinert: Irgendetwas kann immer zu unvorhergesehenen Problemen führen! Alle anderen Fälle sind vorhergesehene Probleme.

            Kommentar

            Lädt...
            X