2016-03-22 9 views
0

直前:モバイルアプリのバックエンドで、タイムゾーンに関する質問が発生する理由です。営業時間はTIME ZONEのTIMESTAMPが必要ですか?

私はちょうどこれの周りに私の頭を得ることができません。私はshop_timesを持っていて、その日の何時から店が開いた日の別の時刻までの情報を保管しています。

私はshop_offerを提供されたその時点で伝えることができるようにしたいので、私はまた、このshop_timesがあったか、または有効である何の期間に伝える間隔を格納します。 A shop_offerそれ自体は有効である期間があります。現時点では、私はこれらすべての間隔でTIMESTAMP WITH TIME ZONEを使用していますが、本当に必要かどうかはわかりません。

ユーザーがロンドンにいて、利用可能なオファーと利用可能時間を見たい場合は、単に店主が定義した日時を送信することができます。私は現地時間としてこれを表示することもできますので、実際にはだと思います。ここではにタイムゾーン情報が必要です。一方

、タイムゾーン情報なしで、私は求めることはできませんので、例えば「 でどのように多くの時間が、この利用可能です」 2016-03-22 08:00:00は、モバイルユーザーが異なるタイムゾーンにいる可能性があるため、十分に説明できません。しかし、よく、私は単に私の shopエンティティにタイムゾーンを格納することができます。結局のところ、それはタイムゾーンを決定する店の場所です。だから、モバイルユーザーがその質問をすると、私はちょうど店のタイムゾーンを送ることができ、彼はこれに対する答えを計算することができます。

またはとし、タイムゾーンの情報を保存する必要がありますか?

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, 

); 

答えて

0

注意すべきいくつかのことを::

  • TIMESTAMP WITH TIME ZONEは、タイムゾーンが格納されていない

    これは私のテーブルが、現在のように見える方法です。これはPostgresが、(1)文字列の解析(2)書式設定文字列(3)時刻がどの曜日に該当するかを判断するときに、現在のTIMEZONEの設定を適用することを意味します。 date_truncまたはextractです。

  • 内部では、TIMESTAMP WITHまたはWITHOUT TIME ZONEは、を表します。それは文字列として格納されません。タイムゾーンは、ユーザーの入力から店舗時間を解析するときや、ショッパーに表示するように書式を設定するときにのみ重要です。あなたがいるタイムゾーンに関係なく、同じ瞬間です。それはちょうど "5pm Eastern"または "2pm Pacific"と書かれています。

あなたはshops.time_zone列とshopper.time_zone列(またはものは何でもあなたのテーブルが呼ばれている)を必要とするように聞こえます。これにより、ユーザーの観点からこれらの時刻を正しく解析/書式設定できます。

You には、「これは何時間ありますか」を計算するためのタイムゾーン情報が必要ですか?NOW()は即時で、オファーの開始時刻は瞬時であり、あなたがいる時間帯にかかわらず、それらの間の差は常に2時間(または何でも)です。

アプリがJSONのデータベースからタイムスタンプを受け取っている場合は、おそらくそれらを文字列として渡している可能性があります。もしそうなら、私はUTCでそれらを渡すことを標準化するので、アプリケーションは簡単にそれらを解釈し、「何時間でこれが利用可能か」のようなクライアント側の計算を行うことができます。

関連する問題