2016-03-22 12 views
0

Kurz vorher: Dies ist das Backend für eine mobile App, weshalb die Frage nach der Zeitzone auftaucht.Benötige ich TIMESTAMP MIT ZEITZONE für Öffnungszeiten?

Ich kann einfach nicht meinen Kopf herumkommen. Ich habe shop_times, die die Information von der Tageszeit bis zu einer anderen Tageszeit des Tages speichern, die ein Geschäft geöffnet hat.

Da ich will ein shop_offer sagen können zu welchem ​​Zeitpunkt angeboten, speichere ich auch das Intervall, das diese shop_times war in welchem ​​Zeitraum erzählt oder gültig ist. A shop_offer selbst hat einen Zeitraum, in dem es gültig ist. Im Moment verwende ich TIMESTAMP WITH TIME ZONE für alle diese Intervalle, aber ich kann nicht sagen, ob ich das wirklich brauche.

Wenn der Benutzer in London ist und die Angebote und die Zeit sehen möchte, zu der sie verfügbar sind, könnte ich ihm einfach das Datum und die Uhrzeit senden, die von einem Ladenbesitzer definiert wurden. Ich könnte dies auch als lokale Zeit anzeigen, so dass dies ist, wo ich glaube, dass nicht brauchen eine Zeitzone Informationen hier.

Auf der anderen Seite, ohne die Information Zeitzone ich nicht fragen kann „in, wie viele Stunden ist diese verfügbar“, weil z.B. 2016-03-22 08:00:00 ist nicht genug zu sagen, da der mobile Benutzer in einer anderen Zeitzone sein könnte. Aber gut, ich könnte einfach die Zeitzone in meiner shop Einheit speichern. Schließlich bestimmt der Standort des Shops die Zeitzone. Wenn also ein mobiler Benutzer diese Frage stellt, kann ich ihm einfach die Zeitzone des Shops schicken und er kann die Antwort darauf berechnen.

Also .. sollte ich die Periodeninformation mit oder ohne Zeitzone Informationen speichern? Diese

ist, wie meine Tabellen zur Zeit wie folgt aussehen:

CREATE TABLE shop_times (

    -- PRIMARY KEY 

    id BIGSERIAL NOT NULL, 

    shop_id BIGINT NOT NULL, 

    CONSTRAINT fk__shop_times__shop 
     FOREIGN KEY (shop_id) 
     REFERENCES shop(id), 

    PRIMARY KEY (id, shop_id), 

    -- ATTRIBUTES 

    valid_from_day TIMESTAMP WITH TIME ZONE NOT NULL, 
    valid_until_day TIMESTAMP WITH TIME ZONE NOT NULL, 

    time_from TIME WITHOUT TIME ZONE NOT NULL, 
    time_to TIME WITHOUT TIME ZONE NOT NULL, 

    -- CONSTRAINTS 

    CHECK(valid_from_day <= valid_until_day), 

    CHECK(time_from < time_to) 

); 


CREATE TABLE shop_offer_time_period (

    -- PRIMARY KEY 

    shop_times_id BIGINT NOT NULL, 

    shop_offer_id BIGINT NOT NULL, 

    shop_id BIGINT NOT NULL, 

    CONSTRAINT fk__shop_offer_time_period__shop_times 
     FOREIGN KEY (shop_times_id, shop_id) 
     REFERENCES shop_times(id, shop_id), 

    CONSTRAINT fk__shop_offer_time_period__shop_offer 
     FOREIGN KEY (shop_offer_id, shop_id) 
     REFERENCES shop_offer(id, shop_id), 

    PRIMARY KEY (shop_times_id, shop_offer_id, shop_id), 

    -- ATTRIBUTES 

    valid_for_days_bitmask INT NOT NULL, 

    price REAL NOT NULL, 

    valid_from_day TIMESTAMP WITH TIME ZONE NOT NULL, 
    valid_until_day TIMESTAMP WITH TIME ZONE NOT NULL, 

); 

Antwort

0

Ein paar Dinge zu beachten:

  • TIMESTAMP WITH TIME ZONEspeichert nicht die Zeitzone. Es bedeutet nur, dass Postgres die aktuelle TIMEZONE Einstellung anwendet, wenn (1) Zeichenketten (2) formatieren Zeichenketten (3) analysieren, die bestimmen, an welchem ​​Tag eine Zeit fällt, z. für date_trunc oder extract.

  • Intern ein TIMESTAMP WITH oder WITHOUT TIME ZONE stellt eine sofortige . Es wird nicht als Zeichenfolge gespeichert. Die Zeitzone spielt nur dann eine Rolle, wenn Sie die Geschäftszeiten anhand von Benutzereingaben analysieren oder wenn Sie sie so formatieren, dass sie einem Käufer angezeigt werden. Egal in welcher Zeitzone Sie sind, es ist der selbe Moment. Es ist nur geschrieben "5pm Eastern" oder "2pm Pacific".

Es klingt wie Sie brauchen eine shops.time_zone Spalte und eine shopper.time_zone Spalte (oder was auch immer Ihre Tabellen genannt werden). Dadurch können Sie diese Zeiten korrekt aus der Perspektive des Benutzers analysieren/formatieren.

Sie nicht brauchen Zeitzone Informationen zu berechnen "in wie viele Stunden ist das zur Verfügung?".Das liegt daran, NOW() ist ein Instant, und die Startzeit des Angebots ist ein Augenblick, und unabhängig davon, in welcher Zeitzone Sie sind, ist der Unterschied zwischen ihnen immer 2 Stunden (oder was auch immer).

Wenn Ihre App Zeitstempel aus der Datenbank in JSON empfängt, werden sie wahrscheinlich als Zeichenfolgen übergeben. Wenn dies der Fall ist, würde ich sie standardisieren, indem ich sie in UTC übergebe, sodass die App sie leicht interpretieren kann und clientseitige Berechnungen wie "in wie vielen Stunden ist dies verfügbar" durchführt.

Verwandte Themen