0

tl;dr : アプリ全体で一貫性を確保するために、Date、Time、Datetime を操作するためのルールは何ですか?

Railsで日付と時刻とゾーンを操作することに頭を悩ませているので、すべての「ユーザー向け」の日付/時刻をタイムゾーンに合わせて調整したいときに誤ってUTCを使用しないようにしています。少なくとも私には矛盾しているように見えることに気づき、その背後にあるルールやロジックを理解したいと思っているので、再び「驚かれる」ことはありません。

1.9.3p194 :028 > e = Event.find(1)
  Event Load (0.3ms)  SELECT "events".* FROM "events" WHERE "events"."id" = $1 LIMIT 1  [["id", 1]]
 => #<Event id: 1, start_at: "2012-08-27 19:15:00", end_at: "2012-08-27 21:00:00", created_at: "2012-08-22 07:43:31", updated_at: "2012-08-23 03:01:59"> 

1.9.3p194 :037 > e.start_at              # <== start_at is DateTime in model
 => Mon, 27 Aug 2012 12:15:00 PDT -07:00  
1.9.3p194 :036 > e.start_at.to_time
 => 2012-08-27 19:15:00 UTC              ### <=== This is in UTC..  ok...

1.9.3p194 :034 > DateTime.now
 => Thu, 23 Aug 2012 10:44:16 -0700      # <=== Also a DateTime
1.9.3p194 :035 > DateTime.now.to_time
 => Thu, 23 Aug 2012 10:44:19 -0700      ### <=== But this is in Pacific Time ?!?

to_time?からの 2 つの異なる応答 それとも私は何かを逃しましたか？

DateTime のto_timeのかなり不可解なドキュメントでは、タイムゾーンについて言及されていません。

to_time() 自分自身を Ruby Time オブジェクトに変換しようとします。Ruby Time クラスの範囲外の場合、self を返します。self に 0 以外のオフセットがある場合、それを Time にマップする明確な方法がないため、self はそのまま返されます。

では、Rails から一貫した日付と時刻を取得するための「ルール」とは何でしょうか?

4

1 に答える 1

1

start_atデータベースに列があると仮定します。結果として、e.start_atのインスタンスではなくDateTime、のインスタンスになりますTime。（電話e.start_at.classしてみてください）

を使用する代わりに、で定義されたタイムゾーンの現在の時刻を返すDateTime.nowRailsを使用することをお勧めします。Time.zone.nowTime.zone

1.9.3p125 :005 > Time.zone
 => (GMT+00:00) UTC 
1.9.3p125 :006 > Time.zone.now
 => Thu, 23 Aug 2012 20:10:34 UTC +00:00 
1.9.3p125 :007 > Time.zone = "Berlin"
 => "Berlin" 
1.9.3p125 :008 > Time.zone
 => (GMT+01:00) Berlin 
1.9.3p125 :009 > Time.zone.now
 => Thu, 23 Aug 2012 22:10:47 CEST +02:00
于 2012-08-23T20:12:48.047 に答える