2017-08-17 2 views
1

La documentation Time.current dit:Pourquoi utiliser Time.current sur Time.zone.now dans Rails, lorsque Time.zone est toujours défini?

retours Time.zone.now lorsque Time.zone ou config.time_zone sont réglés, sinon retourne juste Time.now.

# File activesupport/lib/active_support/core_ext/time/calculations.rb, line 36 
def current 
    ::Time.zone ? ::Time.zone.now : ::Time.now 
end 

Mais quand est Time.zone jamais pas ensemble dans Rails?

# Set Time.zone default to the specified zone and make Active Record auto-convert to this zone. 
# Run "rake -D time" for a list of tasks for finding time zone names. Default is UTC. 
# config.time_zone = 'Berlin' 

J'ai commenté config.time_zone et je reçois encore Time.zone égale à « UTC » comme il définit apparemment que par défaut comme indiqué dans le commentaire. Alors, quel est le point d'utiliser Time.current sur Time.zone.now?

PS: J'observe cela sur Rails 4.1.16

Répondre

1

La réponse courte est qu'il n'y a pas de différence, sauf syntaxe propre/plus courte si vous utilisez Rails comme il est.

Time.zone_default est initialisé en ActiveSupport::Railtie via active_support.initialize_time_zone. Plus d'infos sur le processus d'initialisation de railtie here.

Ma conjecture en raison de cette vérification est que, en tant que cadre, c'est la situation où quelqu'un a retiré ce active_support.initialize_time_zone de son processus de démarrage de rails. Dans ce cas, Time.zone serait nil.