Est-ce que quelqu'un sait-il comment traiter de manière appropriée les fuseaux horaires des utilisateurs dans les rails 2.3?

J'ai eu ce problème lorsque je construisais un système de billetterie de support. Ma solution était la suivante.

Définissez le fuseau horaire de DateTime SQL et Activerecord sur UTC.

Définissez le format de votre temps souhaité dans la configuration de votre application.

Faites une classe CSS pour la façon dont vous souhaitez que le CSS de votre date de regarder. Faire le nom unique. PAR EXEMPLE. Utcdate

Écrire JavaScript pour rechercher la page pour les classes de date nommées DOM (UTCDate ci-dessus). Étant donné que JavaScript est exécuté par l'utilisateur final, il remplacera la valeur avec ce que la machine locale est réglée sur. Dans le cas où vous avez une erreur d'analyse, quittez l'heure en UTC. Regardez ici pour JavaScript pertinent

L'avantage de cette solution est votre application ne dispose pas d'un sélecteur de fuseau horaire stupide comme tant de forums. Il diminue également la charge de la charge du serveur et la taille de la base de code (puisque vous n'avez pas à stocker ou gérer aucune information sur les zones de temps de client) pour gérer une tâche importante mais difficile.

Après une recherche exhaustive, il est maintenant complètement clair que le temps.Zone est cassé dans la plupart des versions des rails (y compris 2.3 et 3). Cette fonctionnalité utilise un hachage de fil central pour stocker la valeur définie (qui est censé être du fil de sécurité, et n'est pas) et finit par modifier le comportement pour toutes les demandes suivantes. De plus, contrairement à la documentation, le réglage du temps.ZONE modifie le comportement ActiveRecord et enregistre les temps de date dans la nouvelle zone, au lieu de celui spécifié dans la configuration (qui est généralement UTC).

jusqu'à ce que les rails obtiennent cela, nous avons choisi de travailler avec Timezones manuellement, qui peuvent être accessibles via la méthode par défaut non documentée: P>

module ActiveSupport #:nodoc:
  module CoreExtensions #:nodoc:
    module Time #:nodoc:
      module ZoneCalculations
        def self.included(base) #:nodoc:
          base.class_eval do
            alias_method_chain :change, :zone
          end
        end

        def change_zone(new_zone)
          new_zone = ::Time.__send__(:get_zone, new_zone)
          return self if new_zone.name == zone
          new_zone.local(year,month,day,hour,min,sec,usec)
        end

        def change_with_zone(options)
          result = change_without_zone(options)
          options[:zone] ? result.change_zone(options[:zone]) : result
        end

      end
    end
  end
  class TimeWithZone
    def change_zone(new_zone)
      time.change_zone(new_zone)
    end
    def change(options)
      time.change(options)
    end
  end

end

class Time
  include ActiveSupport::CoreExtensions::Time::ZoneCalculations
end

Vous avez raison dans ce rails ne réinitialise pas automatiquement le fuseau horaire par demande. L'auteur Wiki donne un exemple dans lequel le fuseau horaire est défini dans un filtre avant, il ne subit donc jamais le problème des zones de temps "fuites" entre les demandes (car le fuseau horaire est configuré correctement avant la demande). L'exemple utilisé dans la documentation RDOC pour Timezone.zone = code> est similaire. Je pense donc que c'est un problème de documentation.

Changer le fuseau horaire ne demande pas local, il est en fil local. Les rails stockent le fuseau horaire sélectionné dans le thread de courant (voir fil.current. [: Time_zone] code>), pas dans la demande actuelle. Comme le même thread gère plusieurs demandes, les modifications apportées au temps.Zone sont persistantes entre les demandes. P>

Je pense que la bonne façon d'utiliser des fuseaux horaires dans votre scénario consiste à utiliser temps.utilisateur code >: P>

def my_action
  Time.zone # 'UTC'
  Time.use_zone('Mountain Time (US & Canada)') do
    Time.zone # 'Mountain Time (US & Canada)'
  end
  Time.zone # 'UTC'
end