Soit ça, soit tu acceptes que ce sera parfois à 2h et parfois à 3h (locale, toujours 17h UTC) selon la période de l’année. La seconde solution me parait plus adaptée pour des jobs "système" (comme les MAJ auto, les backups, les renouvellement de certificats letsencrypt, les rotations de logs...).
Si ton heure locale est significative (par exemple : envoyer quotidiennement un rapport au département comptabilité), tu peux utiliser systemd pour spécifier explicitement dans quelle timezone s’applique tes services planifiés (OnCalendar=08:00:00 Asia/Tokyo) tout en gardant ton serveur en UTC. Mais maintenant faut à nouveau faire gaffe au piège "0 ou 2 envois pendant le changement d’heure".
[^] # Re: ha...
Posté par Moonz . En réponse au journal Manutan, cyberattaque et Windows/Linux. Évalué à 2. Dernière modification le 07 décembre 2021 à 14:25.
Soit ça, soit tu acceptes que ce sera parfois à 2h et parfois à 3h (locale, toujours 17h UTC) selon la période de l’année. La seconde solution me parait plus adaptée pour des jobs "système" (comme les MAJ auto, les backups, les renouvellement de certificats letsencrypt, les rotations de logs...).
Si ton heure locale est significative (par exemple : envoyer quotidiennement un rapport au département comptabilité), tu peux utiliser systemd pour spécifier explicitement dans quelle timezone s’applique tes services planifiés (
OnCalendar=08:00:00 Asia/Tokyo) tout en gardant ton serveur en UTC. Mais maintenant faut à nouveau faire gaffe au piège "0 ou 2 envois pendant le changement d’heure".