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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
publichtml
June 16, 2016
Programming
110
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Railsのtimezone設定(Rails4系の場合)
publichtml
June 16, 2016
More Decks by publichtml
See All by publichtml
初めまして、株式会社万葉です!! @RailsGirlsNagoya4th /everyleaf-on-railsgirlsnagoya4th
publichtml
0
86
ダムで学ぶRailsのRoutes入門
publichtml
2
340
Let's join RailsGirlsTokyo, More!
publichtml
0
97
Other Decks in Programming
See All in Programming
Swift愛好会と私(ウホーイ) / Swift Fan Club and Uhooi
uhooi
0
140
ソフトウェアラスタライザ
fadis
1
790
【DroidKaigi 2026】「アクセシビリティを利用するとき、 アクセシビリティもまたこちらを利用している」 〜マルウェアによる攻撃と防衛について〜
halunoyo
0
410
kubernetes コンポーネント開発入門 / 新卒N年目の勉強会&交流会!〜〇〇への誘い〜 #n_study
mazrean
0
170
Deep dive into the select statement (GopherCon UK)
jespino
0
170
Seeing Through Serverless: Observability for AWS Lambda with ADOT and CloudWatch Application Signals
seike460
PRO
1
120
GraphRAGのKnowledge Graphを 直接!見る/View-GraphRAG's-KnowledgeGraph-directly!
tyumugi1113
0
240
The Good Stuff, Not the Slop: Engineering High-Quality Android Apps with Modern AI Tooling
danybony
1
190
片田舎のおっさん、 Swift Buildのダイアモンド問題解決の不具合修正PRを出すが、解決方法がキャッシュをしないようにすることであり、ビルド時間が伸びると言われてマージされないので高速化もする/swiftbuild
yimajo
0
360
AIを上手に使っていこうとしたら越境せざるを得なくなった話 〜実践1年で見えた境界を越えなければならない理由と進め方〜 / Crossing borders with AI
tomoyakitaura
3
1.1k
週末にAI-DLCを本気で回したら$1,600溶けた
hbashimizu
0
130
Go 1.27からのGODEBUG / Go 1.27 リリースパーティ #go127party
mazrean
0
320
Featured
See All Featured
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
67
58k
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.4k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
3k
AI: The stuff that nobody shows you
jnunemaker
PRO
9
970
Speed Design
sergeychernyshev
33
2.1k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
690
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
470
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
How GitHub (no longer) Works
holman
316
150k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Language of Interfaces
destraynor
162
27k
Into the Great Unknown - MozCon
thekraken
41
2.7k
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