Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Railsのtimezone設定(Rails4系の場合)
Search
publichtml
June 16, 2016
Programming
0
95
Railsのtimezone設定(Rails4系の場合)
publichtml
June 16, 2016
Tweet
Share
More Decks by publichtml
See All by publichtml
初めまして、株式会社万葉です!! @RailsGirlsNagoya4th /everyleaf-on-railsgirlsnagoya4th
publichtml
0
78
ダムで学ぶRailsのRoutes入門
publichtml
2
330
Let's join RailsGirlsTokyo, More!
publichtml
0
88
Other Decks in Programming
See All in Programming
0626 Findy Product Manager LT Night_高田スライド_speaker deck用
mana_takada
0
110
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
110
Gleamという選択肢
comamoca
6
760
KotlinConf 2025 現地で感じたServer-Side Kotlin
n_takehata
1
230
すべてのコンテキストを、 ユーザー価値に変える
applism118
2
820
AIコーディング道場勉強会#2 君(エンジニア)たちはどう生きるか
misakiotb
1
250
deno-redisの紹介とJSRパッケージの運用について (toranoana.deno #21)
uki00a
0
150
Julia という言語について (FP in Julia « SIDE: F ») for 関数型まつり2025
antimon2
3
980
生成AIコーディングとの向き合い方、AIと共創するという考え方 / How to deal with generative AI coding and the concept of co-creating with AI
seike460
PRO
1
330
AWS CDKの推しポイント 〜CloudFormationと比較してみた〜
akihisaikeda
3
310
C++20 射影変換
faithandbrave
0
530
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
190
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Gamification - CAS2011
davidbonilla
81
5.3k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
The World Runs on Bad Software
bkeepers
PRO
69
11k
GraphQLとの向き合い方2022年版
quramy
48
14k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
790
Thoughts on Productivity
jonyablonski
69
4.7k
Speed Design
sergeychernyshev
32
1k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Transcript
Railsのtimezone設定 (Rails4系の場合) 2016/06/16
Railsの2種類のtimezone設定 • confg.time_zone – 各地の都市名を指定(e.g. 'Tokyo') – アプリ内で使われるタイムゾーン “Time.zone” の
default値 • confg.active_record.default_timezone – :utc or :local – DBに保存するタイムゾーン どちらも confg/application.rb に書く
例えば、こんな風にRailsアプリが あるとするじゃろ? DB Active Record Railsアプリ
役割分担はこうじゃ DB Active Record Railsアプリ confg.active_record. default_timezone confg.time_zone アプリ内タイムゾーン DBに保存するタイムゾーン
まず左側 DB Active Record Railsアプリ confg.active_record. default_timezone confg.time_zone アプリ内タイムゾーン DBに保存するタイムゾーン
confg.time_zone • アプリ内で使われるタイムゾーン “Time.zone” のdefault値 • defaultということは上書きできる • 複数タイムゾーンを扱うアプリは、リクエスト 毎にログインユーザに合わせて切り替えるのが
定番 • 設定さえしておけば、後のタイムゾーン変換は ActiveRecordにお任せ
たぶん定番的な書き方 すべてのControllerの基底クラス(ApplicationController) で、ログインユーザに合わせて上書き class ApplicationContoller < ActionController::Base before_action :set_timezone def
set_timezone # ログインユーザのtimezoneで上書き Time.zone = current_user.timezone if current_user end # ログインユーザを返すメソッド def current_user # ... end end
ActiveRecordによる自動変換 Railsアプリ Time.zone=“America/New_York” DB start_at = '2017-01-01 13:00:00 UTC' start_at
= '2017-01-01 08:00:00 EST-05' Railsアプリ Time.zoneさえ設定しておけば、後はActiveRecordが DBの値の取得/保存時に自動変換してくれる Railsアプリ DB start_at = '2017-01-01 13:00:00 UTC' start_at = '2017-01-01 22:00:00 JST_09' Time.zone=“Asia/Tokyo”
便利!!
次は右側 DB Active Record Railsアプリ confg.active_record. default_timezone confg.time_zone アプリ内タイムゾーン DBに保存するタイムゾーン
confg.active_record. default_timezone • DBに保存する値に適用するtimezone – 日時はTime.zoneからこのタイムゾーンに変換され る • 逆に「DB内の日時をすべてこのタイムゾーン で解釈する」という基準タイムゾーンでもある
設定可能な値 • :utc – すべての日時をUTCとして扱う • :local – すべての日時をWebサーバ(Railsが動くサーバ)の システムのタイムゾーンとして扱う
• 実はActiveRecordは、DBサーバやDB自体の タイムゾーン設定を全く考慮しない – ※ MySQLの場合
:utc設定の場合 Railsアプリ DB time_zone= UTC start_at = '2017-01-01 13:00:00 UTC'
DB time_zone= EST start_at = '2017-01-01 13:00:00 EST' DB time_zone= JST start_at = '2017-01-01 13:00:00 JST' ActiveRecord start_atを リクエスト Time.zoneに 合わせて 自動変換された 値を返す DBがどの場合でも '2017-01-01 13:00:00 UTC' として解釈
:local設定の場合 • :utcの場合と同様、接続先DBのタイムゾーン 設定に関わらず、すべての日時をWebサーバ のシステムのタイムゾーンで保存されたもの と解釈する ※ Webサーバ複数台構成の場合は、すべての サーバのタイムゾーンを揃えることに特に注 意しましょう
:utcと:localの使い分け • 国際化対応する場合はとりあえず標準ぽい :utcがお薦め – 複数国のそれぞれシステムタイムゾーンが違うサーバに置いて も大丈夫 – Railsのdefaultでもある •
国際化不要で、DBの生データの見易さ重視なら :local – 手動更新作業や他のアプリがDBを修正する時に、タイムゾーン 変換不要な方がミスが起こりにくい • 究極的にはケースバイケース • (個人的には、DBのタイムゾーン設定とRailsが保存する タイムゾーンは極力同じにしておきたい) – RailsはDBの設定は見ないけど、何かあった時に混乱の元
END