Let's say I and the partner company I'm dealing with live in a country that employs Daylight Saving Time.

I have a CronJob in a kubernetes cluster that uploads files to the partner company daily at, say, 4:00, 10:00, 16:00, and 22:00. E.g. 0 4,10,16,22 * * *.

Kubernets SIG decided that CronJob object will not support local timezone and will always run in the default one, which is UTC.

I can change the schedule, so that it reflects local time specified above in UTC and give the CronJob that schedule. However everytime daylight saving kicks in (twice a year) I would need somehow modify all the CronJobs to use the new time, and I need to modify my deployment pipeline to create new releases of the CronJobs with the new time.

I cannot keep the CronJob running on the same schedule past daylight saving change, as the job will upload files not during the times expected by the partner.

What is the easiest way to manage this?

Option 1

It was suggested that writing a new kubernetes controller could do, but it does not seem that anyone raised up to that challenge and published working solution.

Option 2

Another option I have considered is changing the timezone of the entire cluster. But if you google it it does not seem to be very popular solution, and some people strongly believe that kubernetes being a cloud application should be run in UTC.

From what I understand cron uses a local time zone which, in case of kubernetes will be the timezone of the controller manager, which is not necessary a timezone of the node it is running on. On the other hand, changing time zone of the controller manager container, sounds risky, as it is not clear how it will interact with other components of the kubernetes, such as etcd and kubelets.

Option 3

Doing it manually twice a year. Since people in the organisation come and go it would be difficult to retain the knowledge when and how. I do not want our partner to complain twice a year. Also it might be tricky to set up notifications for this as the dates change every year.

Option 4

Write some homegrown automation to run twice a year and hope that when time comes it works as expected. That is actually triggers, triggers at the right time and does everything it's supposed to do. (the latter is easier to test but the former is harder).

All these options feel quite unsatisfactory. I googled a lot and I have not found a lot, I feel it should be quite common issue, and yet nothing comes up in the search. Am I overlooking something? Is there an easy and natural way to solve it?