1

私はAPI次のようなものを持っています

/summary/yyyy/mm
  • 要求された年と月のデータの概要を返します。
  • これが現在の年と月の場合、残りの日数を返すものの 1 つです。例:サーバー上の現在の日付days_left: 9は20131021 Oct 2013

残り日数の計算方法
これはPythonで次のように実装されています

def current_financial_month_details(self):
        time_from, time_to = self \
            .get_start_end_time_current_financial_month()

        today = datetime.today()
        from_time = datetime(year=today.year, month=today.month,
                             day=today.day)
        return {
            'time_from': time_from,
            'time_to': time_to,
            'remaining_days': (time_to - from_time).days
        }

問題？

  • サーバーは東海岸にあり、クライアント (ブラウザを使用している) は太平洋時間帯にあります
  • PST の午後 9 時に東海岸の時刻が変わるため、hit を実行する/summary/2013/10とOct 21 2013、PST の場合、日付は EST で既に変更されているためdays_left: 8、クライアント側では正しくありません。右？

この状況をどのように処理しますか?

4

2 に答える 2

4

ほとんどの人は、地理的な場所から独立したタイムゾーン (最も一般的には UTC) で日付と時刻を保存することをベストプラクティスと考えています。異なるタイムゾーンの場所からアクセスされる (または最終的にアクセスされる可能性がある)サービスがある場合も、同じことが当てはまります。

J0HN が述べたように、クライアントは、サーバーとやり取りするときに UTC との間の変換を行う必要があります。あなたの場合、これはdays_left現在の UTC 日付と月末 (UTC) の間の日数として定義する必要があります。

特に python の場合、 naive と timezone-awareの 2 種類のdatetime.datetimeオブジェクトがあります。単純な日時はタイムゾーン情報を添付しないため、(ネットワーク化されたプログラムでは) UTC タイムゾーンの時間には単純な日時のみを使用することをお勧めします。計算を行う (たとえば、2 つの日付を減算する) には、の代わりに を使用することを検討してください。これにより、 DSTによって引き起こされる間違った時間差を含む (ただしこれに限定されません) タイムゾーンに関連する問題を回避できます。datetime.utcnowdatetime.now

他のタイムゾーンを処理する必要がある場合(たとえば、ユーザーに表示するため)、外部ライブラリを使用する必要がある場合があります。これは、Python 自体がタイムゾーン データベースを提供しないためです。この質問には、それに関する詳細情報があります。

于 2013-10-21T16:22:16.243 に答える
1

いくつかの選択肢があります。

1 つ目は、結果が配信されるタイム ゾーンを指定し、クライアントが不一致を受け入れることを期待することです。明らかな選択肢は、サーバーのタイムゾーンまたは UTC です。

2 つ目は、API が現在の日付と日数も返すようにすることです。結果は変わりませんが、少なくとも、日付が予想していたものと異なることを検出できます。

3 つ目は、サーバーがその処理を調整できるように、API にタイム ゾーンの入力を取得させることです。

4 つ目は、たとえば午前 5 時など、午前 0 時以外の時間に日付を変更することです。これは、クライアントがすべて同様のタイムゾーンにあり、アクティビティが 24 時間体制ではない場合にのみ機能します。中国にクライアントがいる場合、おそらくこのオプションを後悔するでしょう。

于 2013-10-21T16:22:58.140 に答える