Hostpoint ou OVHcloud pour corriger une date de réservation WordPress

Une confirmation peut afficher la veille alors que la réservation est correcte

Un client choisit le 1er décembre à 00 h 30 pour un événement à Paris. La page de réservation et la fiche du rendez-vous affichent le créneau attendu. Pourtant, dans l’aperçu de la confirmation, la date devient le 30 novembre à 23 h 30. Avant de modifier le rendez-vous, relevez l’instant enregistré et le fuseau qui doit servir à l’affichage. Dans cet exemple, les deux dates peuvent désigner exactement le même instant. La confirmation a simplement utilisé une autre heure locale.

Le cas traité concerne une extension ou un modèle WordPress qui confie l’affichage de la date à `IntlDateFormatter`. Même si l’objet PHP transmis au formateur a déjà été converti vers `Europe/Paris`, la méthode `format()` utilise le fuseau configuré dans le formateur. Si le constructeur reçoit `null` pour ce fuseau et qu’aucun calendrier Intl explicite n’intervient, il utilise le fuseau PHP par défaut. Une configuration de recette en UTC suffit alors à reproduire le décalage sans modifier la valeur enregistrée.

Comparez l’aperçu de confirmation à une page qui affiche le même rendez-vous. Si les écrans divergent, notez le contexte de génération de chacun. La confirmation peut être produite lors d’une requête web ou par un traitement différé. Le bon endroit pour observer les réglages est le traitement qui génère la date en erreur. Le comparatif oppose deux chemins documentés pour retrouver le contexte PHP chez Hostpoint et OVHcloud, puis une correction qui choisit le fuseau dans le code d’affichage.

Relever l’instant et le fuseau métier avant de corriger

Sur une copie privée du site, créez un rendez-vous fictif à une heure proche de minuit. Relevez l’identifiant de réservation et l’instant enregistré avec son décalage explicite ou son équivalent UTC. Si l’extension stocke une date sans décalage, identifiez d’abord le fuseau qui lui donne son sens dans le format documenté. Une chaîne comme `2026-12-01 00:30` peut représenter des instants différents selon le contexte dans lequel on la lit. Évitez de la convertir une seconde fois après qu’un autre composant l’a interprétée.

Consignez le fuseau du lieu de l’événement, le fuseau du site WordPress et le fuseau utilisé pour la confirmation. Pour une réservation locale, le fuseau métier peut venir de la fiche du lieu. Si toutes les réservations du site suivent la même heure, il peut s’agir du fuseau configuré dans Réglages → Général. Pour une équipe qui organise des événements dans plusieurs pays, précisez aussi si le destinataire doit voir l’heure du lieu, son heure locale ou les deux. La même valeur UTC peut s’afficher sous plusieurs dates légitimes.

Vérifiez enfin si la différence concerne une seule étiquette ou l’instant réellement réservé. Comparez l’instant UTC de la fiche avec celui que la confirmation utilise comme entrée. S’ils sont identiques et que seul le texte diverge, intervenez sur le formateur. S’ils diffèrent déjà, remontez au moment où l’extension interprète l’heure choisie et stocke la réservation. Cette distinction évite de déplacer le rendez-vous pour résoudre un problème d’affichage.

• Créer une réservation fictive et relever son identifiant, son instant UTC et le fuseau métier attendu.
• Comparer la fiche, l’aperçu de confirmation et, si nécessaire, le traitement différé qui génère le texte.

Observer le formateur dans le contexte réel de la confirmation

Demandez au mainteneur de relever, pour le rendez-vous de recette, la version PHP, le contexte d’exécution, la présence de l’extension `intl` et la valeur renvoyée par `date_default_timezone_get()`. Si le composant utilise `IntlDateFormatter`, relevez aussi son identifiant de fuseau avec `getTimeZoneId()`. Un diagnostic PHP lancé depuis le terminal indique les réglages de cette commande. Pour une confirmation produite par une requête web, vérifiez la même information depuis le contexte web. Pour une tâche de fond, contrôlez aussi le processus qui la traite.

Une valeur implicite peut paraître correcte parce que le serveur de développement ou la date de test donne le même décalage que le lieu. Rejouez avec un instant d’hiver et un instant d’été proches de minuit. `Europe/Paris` applique les règles du fuseau nommé. Un décalage fixe `+01:00` peut donner la bonne date en hiver et la veille en été. Le choix de la langue ne corrige pas ce problème. Un libellé français peut toujours afficher l’heure UTC ou une date d’un autre jour.

Sur la recette, utilisez un aperçu, un journal privé ou une destination de test réservée à l’équipe. Relevez seulement l’identifiant fictif et les valeurs nécessaires au diagnostic. Après avoir corrigé le formateur, vérifiez que les deux libellés correspondent à la date locale attendue et que les horodatages d’entrée sont restés identiques. Vérifiez aussi un créneau ordinaire en journée, afin de contrôler que le changement de format n’a pas introduit un autre décalage.

Hostpoint Standard, retrouver l’environnement PHP du site

Dans le Control Panel Hostpoint, sélectionnez l’hébergement et le domaine de recette. Ouvrez Sites Web → Réglages Web, puis Configuration PHP. Hostpoint documente aussi des réglages par répertoire et indique que les options PHP du site sont enregistrées dans `.user.ini` à la racine de document. Pour ce diagnostic, commencez par une lecture. Notez le site et la version de PHP qui exécutent l’aperçu, puis comparez-les au traitement qui génère la confirmation.

Hostpoint cite `intl` parmi les extensions généralement installées et précise que leur disponibilité peut varier. Une liste dans la documentation ne remplace donc pas `extension_loaded('intl')` dans le contexte de recette. Si cette lecture est vraie, examinez le fuseau du formateur. Si elle est fausse, vérifiez d’abord que le module manque bien dans le traitement concerné. Une commande en SSH exécutée avec un autre PHP peut donner un résultat différent. Un incident qui ne concerne qu’un seul site mérite une vérification ciblée avant toute modification partagée.

Si vous changez un réglage PHP à titre de test, conservez la configuration du domaine avant de le faire et reprenez une page ordinaire après l’essai. Pour une date incorrecte avec `intl` déjà présent, une correction du formateur est plus précise qu’un changement de profil PHP. L’extension peut aussi fournir une option de fuseau de réservation. Dans ce cas, vérifiez que cette option est prise en compte dans l’aperçu et par le traitement qui produit la confirmation.

OVHcloud Perso, identifier le contexte d’exécution du domaine

Dans l’espace client OVHcloud, ouvrez Web Cloud → Hébergements et sélectionnez l’hébergement qui sert le domaine de recette. La documentation décrit les réglages de version et d’environnement PHP depuis l’espace client et via `.ovhconfig`. Elle précise que `php.ini` n’est pas personnalisable sur le mutualisé. Relevez le moteur et la version PHP qui s’appliquent à votre domaine. Si vous utilisez une copie dans un autre répertoire, vérifiez quel fichier et quelle configuration s’y appliquent avant de comparer ses résultats au site principal.

Dans le code de recette autorisé, vérifiez la présence de `intl` et le fuseau dans le même type de traitement que celui qui génère la confirmation. En cas de module absent, demandez quelle combinaison d’environnement et de version est compatible avec l’extension WordPress, ou utilisez une solution d’affichage intégrée à WordPress si le code le permet. Modifier la version PHP peut changer d’autres comportements du site. Faites l’essai sur la copie et relevez la configuration à restaurer avant de tester une version différente.

Si la valeur UTC d’entrée est correcte et que le formateur l’affiche dans un fuseau inattendu, corrigez l’affichage au niveau de l’extension ou du modèle. Un changement de configuration générale peut avoir des effets sur d’autres dates et processus. À l’inverse, une correction du seul formateur permet de rejouer les deux réservations fictives et de comparer les résultats avant de toucher à une tâche ou à un site voisin.

Offres, tarifs et renouvellement au 11 novembre 2026

Hostpoint Standard est affiché à 15,90 CHF par mois. Le catalogue indique des prix TVA incluse. Douze mois à ce repère représentent 190,80 CHF. L’aide indique des durées de 6, 12 ou 24 mois pour l’hébergement web, puis une reconduction automatique de même durée si la résiliation n’intervient pas dans le délai de 30 jours avant échéance. Le montant effectivement dû et le tarif de reconduction se vérifient pour le contrat choisi. L’offre annonce 100 Go NVMe, dix domaines et dix bases MariaDB.

OVHcloud Perso, gamme Eco, affiche 2,99 € HT par mois, soit 3,59 € TTC par mois au tarif public affiché, et un total de 35,88 € HT pour douze mois. Le prix de renouvellement indiqué est de 5,99 € HT par mois, soit 71,88 € HT sur douze mois à ce taux. L’offre annonce 100 Go de stockage et cinq bases de 1 Go chacune. Le récapitulatif de la commande permet de vérifier le cycle, la fiscalité et l’échéance de renouvellement. Un contrat déjà en cours peut avoir ses propres conditions.

Comparez séparément le montant du premier cycle et celui de la reconduction dans la devise de chaque fournisseur. Si plusieurs domaines partagent l’hébergement, vérifiez qu’une copie privée peut reproduire les paramètres du domaine concerné. Le volume de disque et le nombre de bases aident à dimensionner cette copie. Pour l’incident étudié, l’information décisive reste le fuseau effectif du formateur, dans la requête ou le processus qui compose la date.

Choisir un fuseau explicite dans le formateur

Dans un modèle personnalisé qui utilise déjà Intl, transmettez le fuseau de l’événement au constructeur. Pour l’événement fictif de Paris, passez `new DateTimeZone('Europe/Paris')` au paramètre `timezone`. Gardez le véritable instant issu de la réservation, par exemple sous la forme d’un horodatage Unix ou d’un objet qui le représente. Le test joint utilise le même objet pour le formateur implicite et le formateur explicite. Seul le réglage de présentation change. Vous pouvez conserver le format de date attendu en français tout en choisissant le fuseau séparément.

Quand l’extension suit toujours le fuseau du site, elle peut le lire depuis WordPress. Pour un service qui affiche l’heure de plusieurs lieux, choisissez le fuseau de la réservation et vérifiez que sa valeur existe dans le paramétrage du lieu. La date de la confirmation doit correspondre à la convention annoncée au client. Gardez le fuseau dans le relevé de recette, surtout si le même modèle est utilisé pour des événements dans plusieurs villes. Si le fuseau de la réservation est manquant, faites afficher la date seulement selon la règle de secours validée par l’équipe.

Testez deux réservations près de minuit, une en hiver et une en été, et comparez-les à un créneau de journée. Relevez l’identifiant de fuseau renvoyé par le formateur. Si la confirmation et l’aperçu n’utilisent pas le même code, appliquez la correction au point qui produit réellement le texte. Pour revenir en arrière, restaurez le modèle précédent depuis la copie sauvegardée. Les réservations témoins peuvent conserver les mêmes instants pour contrôler le retour, puisque la modification porte sur le format d’affichage.

• Passer un fuseau nommé au formateur et conserver l’horodatage Unix en entrée.
• Comparer les dates affichées en été et en hiver avec l’identifiant de fuseau relevé.

Utiliser l’affichage WordPress lorsque le modèle le permet

Si le modèle a seulement besoin d’une date localisée dans WordPress, utilisez l’API documentée `wp_date()`. Elle accepte un horodatage Unix véritable et un fuseau explicite. Dans un modèle chargé par WordPress, un exemple de rendu est `wp_date('l j F Y H:i', $timestamp, $fuseau)`, avec `$timestamp` issu de la réservation et `$fuseau` comme objet `DateTimeZone` du lieu. Si le site constitue le périmètre de référence, la fonction peut prendre son fuseau par défaut. Préparez le format et la langue attendus dans le contexte où le modèle est rendu.

Le masque PHP de `wp_date()` et le masque ICU d’`IntlDateFormatter` emploient des syntaxes différentes. Reprenez le format voulu et vérifiez un libellé de référence avant de remplacer l’appel. L’exercice PHP comporte aussi une sortie numérique avec `DateTimeImmutable` lorsque `intl` est absent. Elle sert de témoin pour vérifier le jour et l’heure. Si le produit attend des noms de jours et de mois, faites valider le rendu localisé du modèle ou affichez le résultat numérique uniquement selon la convention choisie.

Dans une extension tierce, vérifiez si l’éditeur fournit un réglage de fuseau ou un modèle de confirmation personnalisable. Une modification directe d’un fichier de l’extension risque d’être écrasée lors de sa prochaine mise à jour. Sur la copie, validez le remplacement au moyen du point d’extension prévu et rejouez l’aperçu après une réinstallation ou une mise à jour de recette. Conservez une copie du modèle et la procédure de restauration. Cette vérification donne à l’équipe un moyen de revenir au rendu précédent sans réinterpréter les rendez-vous déjà stockés.

Deux dates limites rejouées sur le serveur PHP local

Le premier témoin est le 30 novembre à 23 h 30 UTC. Avec PHP en UTC et le fuseau du formateur laissé implicite, le résultat reste le 30 novembre. En précisant `Europe/Paris`, il devient le 1er décembre à 00 h 30. Le second témoin est le 30 juin à 22 h 30 UTC. À Paris, il devient le 1er juillet à 00 h 30. Un décalage fixe `+01:00` donne le 30 juin à 23 h 30. Les deux dates de départ sont fictives et servent à rendre visible le changement de jour.

La recette a utilisé Python 3.14.4, PHP 8.4.8 et ICU 75.1. Elle effectue de vraies requêtes sur la boucle locale avec et sans chargement de l’extension Intl. Les huit contrôles passent depuis le ZIP extrait. Le rapport montre les fuseaux effectivement utilisés, les libellés et les horodatages. Le test exerce la classe PHP et le format numérique de secours. Les parcours Hostpoint et OVHcloud et l’usage de `wp_date()` reposent sur leur documentation publique.

Hostpoint Standard offre un repère dans les réglages web du site et documente le module Intl parmi ceux généralement disponibles. OVHcloud Perso fournit un chemin pour vérifier l’environnement PHP, avec des réglages différents sur le mutualisé. Dans les deux cas, confirmez le comportement depuis le code qui compose l’aperçu ou la confirmation. Retenez l’offre dont vous pouvez vérifier le contexte d’exécution et la procédure de retour au modèle précédent, puis signez le résultat sur les deux dates témoins et sur un rendez-vous de journée.

• Extraire le ZIP et lancer `python recette.py` avec PHP et son extension Intl chargeable.
• Comparer les libellés, les fuseaux et les horodatages dans les cas d’été et d’hiver.

Pour aller plus loin

• Lire la fiche Hostpoint
• Lire la fiche OVHcloud
• Comparer les extensions de réservation WordPress
• Télécharger la recette des dates de réservation (ZIP)