8

通常保存されている時刻データを削除する必要があるかどうか疑問に思っています。を使用してpostgresおりnode.js、DateTime が API から返される場所は次のとおりです。

2013-07-01T00:00:00.000Z

ただし、このフィールドは日付のみを表す必要があるため、次のように返す前に再フォーマットすると、時間が関係ないことがより明確になると思います。

2013-07-01

考え？

4

2 に答える 2

6

カレンダーの日付を表している場合、時間やタイムゾーンはありません。短い表現の方が理にかなっています。

残念ながら、多くの JavaScript 実装の new Date(string) は、あなたに悪いことをする可能性があります。

new Date('2015-09-23')
Tue Sep 22 2015 20:00:00 GMT-0400 (Eastern Daylight Time)

この問題を解決する最も簡単な方法は、javascript の Date を使用しないことです。この型は、他の言語の DateTimeOffset と一致します。カレンダーの日付値を表す方法としては不適切です。

しかし、とにかく JavaScript の Date を使用することになるでしょう。次の最も簡単な「修正」は、標準表現を避けることです (標準表現は UTC で DateTimeOffset として解釈されるため)。次の 2 つの可能性があります。

「-」の代わりに「/」を使用します。

new Date('2015/09/23')
Wed Sep 23 2015 00:00:00 GMT-0400 (Eastern Daylight Time)

3 桁の月を使用してください。先頭のゼロは破棄されます。

new Date('2015-009-23')
Wed Sep 23 2015 00:00:00 GMT-0400 (Eastern Daylight Time)

クライアント側とサーバー側の両方に JavaScript がある場合は、完了です。サーバー側に何か他のものがある場合は、非標準の日付形式が入ってきた場合にサーバー言語が何をするかを検討する必要があります.

于 2015-09-23T14:21:28.177 に答える
1

API ユーザーとして、私はむしろ長い形式の日付を受け取りたいと思っています。

いくつかの理由から:

  1. タイム ゾーン: 長い形式には、実際にはタイム ゾーンが組み込まれています。これは重要です。
  2. 解析: ほとんどの言語は、その長い形式をネイティブの「日付」オブジェクトとして読み取ることができます。C# や Java などの一部の言語では、正しいタイム ゾーンを使用するように短い日付を強制する必要があります。また、長い形式で月/日の混乱を避けることもできます。
  3. 比較: ユーザーが短い日付を渡した場合、APIはそれを正しく処理しますか? 優れた API は、内外で同じように見える必要があります。
于 2013-07-11T22:42:51.887 に答える