Faites attention avec @run_date dans les requêtes planifiées BigQuery - Surtout dans KST/JST !

Dans Google BigQuery, la fonction @run_date définit automatiquement la date de référence d'une requête à l'heure de son exécution, mais uniquement lorsqu'elle est exécutée manuellement à partir de l'interface de requêtes planifiées. Lorsqu'elle est configurée pour s'exécuter automatiquement à une heure planifiée sans définir explicitement le fuseau horaire, la requête s'exécute en UTC. Cela peut entraîner un comportement inattendu, notamment si la requête s'exécute à minuit UTC, ce qui fait que @run_date évalue à la date précédente dans le temps local. C'est particulièrement problématique pour les pays comme la Corée du Sud ou le Japon, qui sont UTC+9. Pour éviter ce problème, il est essentiel de définir le fuseau horaire explicitement lors de la planification des requêtes. De plus, utiliser @run_time au lieu de @run_date permet de contrôler l'heure exacte avec le fuseau horaire. Lors de l'utilisation de @run_time, il n'est pas nécessaire de l'entourer de DATE() sauf si cela est requis. Les exemples de définition du fuseau horaire incluent DATE(@run_time, 'Asia/Seoul') et DATE(@run_time, 'Asia/Tokyo'). De nombreux entrepôts de données construits sans prise en compte du fuseau horaire nécessiteront des corrections, mais la définition explicite du fuseau horaire peut prévenir de tels problèmes.