web-dev-qa-db-fra.com

Date ou DateTime dans la base de données pour le développement de composants à l'aide de fuseaux horaires?

Notre composant gère la programmation télévisuelle. Les dates et heures sont donc essentielles. Voici le scénario:

  1. Notre serveur et la plupart des producteurs sont tous à l'heure locale, heure du Pacifique (America/Los_Angeles, UTC + 8)
  2. Joomla est configuré avec le fuseau horaire "America/Los_Angeles" (public $offset = 'America/Los_Angeles';) parce que IS le fuseau horaire dans lequel nous nous trouvons.
  3. La base de données possède un champ date spécifiant quand l'épisode est programmé à diffuser - l'heure actuelle est inconnue.
  4. Il comporte également un champ datetime indiquant le moment où l'épisode a été en fait diffusé, y compris l'heure à laquelle il a été diffusé.

La date programmée de l'épisode en question est "2015-01-02" (l'heure est inconnue). En utilisant un type de champ Calendrier, il affiche toujours le 01/01/2015, probablement parce qu'il est par défaut 00:00:00 comme heure et en soustrayant 8 heures en raison du décalage.

Donc, la question qui se pose est la suivante:

  1. Est-ce que le type de champ de calendrier a un bogue parce que c'est un calendrier, pas une horloge, donc ne devrait pas tenir compte de l'heure,
  2. ou devrions-nous configurer Joomla pour utiliser le fuseau horaire UTC?
  3. ou est-ce que je manque quelque chose de fondamental ici?

Enfin, si la date affichée va "fluctuer", existe-t-il une méthode recommandée pour informer l'utilisateur du fuseau horaire en cours de lecture? L'épisode sera diffusé le 2 janvier, heure locale, mais le calendrier affichera le 1er janvier.

Je m'excuse pour la confusion générale qui règne dans la question. Je suis à la poursuite de cette question depuis un moment et je ne suis pas sûr de la structure du fuseau horaire sur laquelle Joomla fonctionne, donc quelle devrait être la sortie attendue.

En outre:

Je n'utilise pas JHtml::calendar directement, mais via mon formulaire:

<field name="first_aired" type="calendar"
    label="COM_PASS_EPISODES_EPISODES_FIRST_AIRED_PLANNED_LABEL"
    description="COM_PASS_EPISODES_EPISODES_FIRST_AIRED_DESC"
    class="required span2 validate-airdate"
    default="NOW"
    format="%Y-%m-%d"
    />

Le code dans libraries\joomla\form\fields\calendar.php fait sa chose, utilise simplement

return JHtml::_('calendar', $this->value, $this->name, $this->id, $format, $attributes);

Découverte ultérieure

Les docs champ du calendrier indiquent que seuls les éléments SERVER_UTC ou USER_UTC sont autorisés pour l'élément facultatif filter et que vous l'omettez ou que vous spécifiez "" par défaut à USER_UTC mais spécifiant quoi que ce soit invalide saute le code qui ajoute le décalage, affiche donc la date réelle indépendamment du fait d'avoir une heure ou non.

developmentdatabaseform-fields-types
3
GDP

Comme Lodder l'a indiqué plus haut dans les commentaires, le champ du calendrier est enregistré dans la base de données au format UTC. Mais ... uniquement si vous utilisez filter="USER_UTC" Ou filter="SERVER_UTC" Dans le fichier XML, puis validez votre formulaire à l'aide de la méthode validate(). La magie se passe dans la méthode filterField () de JForm qui convertit la valeur en UTC.

Lorsque vous définissez la date, vous devez toujours penser à votre heure locale. Donc, si votre épisode a une date programmée de "2015-01-02" (UTC), votre heure locale est UTC et le serveur exécute "America/Los_Angeles" (UTC-8) et que vous définissez "2015-01-02", puis le champ de calendrier doit afficher "2015-01-02" pour vous, mais pas "2015-01-01". Si vous essayez de modifier votre fuseau horaire en UTC-1 par exemple, le message "2015-01-01" devrait s'afficher, car il s'agira du "2015-01-01 23:00:00". Mais pour tous sur le site Web, ce sera "2015-01-01 16:00:00" (UTC-8).

Mais il y a un comportement étrange. Lorsque vous omettez ce filtre, la valeur d'affichage par défaut est USER_UTC. C'est bon. Mais lorsque vous validez le formulaire, il n'utilisera pas USER_UTC Comme filtre et n'enregistrera pas la valeur telle quelle. Le résultat est évident et déroutant - le champ du calendrier changera toujours l'heure. Donc, si vous omettez, vous devriez convertir vous-même en UTC.

Est-ce un bug? Je ne suis pas sûr.

P.S. Je pense que nous devrions ajouter ceci à doc ?

1
Dmitry Rekun