CronJobs should support timezones

[iterion]

I couldn't find any discussion of this after searching for "cron timezone", "cronjob timezone", or "scheduledjob timezone".

The CronJob spec makes reference to https://en.wikipedia.org/wiki/Cron. That page suggests that cron would respect the timezone for a given user. The controller manager runs in a single time zone under a single user so I can't use different time zones for each job. I have jobs that run based on the schedule of external entities that observe daylight savings time. So, if I define that CronJob in UTC I will be forced to update that job from time to time (generally not something one remembers to do after just losing an hour of sleep).

I see two options for how this support might work in kubernetes:

1. Add some new field to the CronJobSpec, like timezone: "Americas/Chicago".
2. Use an extended cron syntax that includes timezone, e.g. 30 6 * * 1 Europe/Stockholm

[k8s-github-robot]

@iterion There are no sig labels on this issue. Please add a sig label by:
(1) mentioning a sig: @kubernetes/sig-<team-name>-misc
(2) specifying the label manually: /sig <label>

Note: method (1) will trigger a notification to the team. You can find the team list here and label list here

[xiangpengzhao]

/sig apps

[xingzhou]

Prefer the second option as it's looks more nature to me

[0xmichalis]

@soltysh @kubernetes/sig-apps-feature-requests

[iterion]

I also like the second form, but it seems that the easiest path to implementation would be to strip that time off and use it separately. Also, an argument could be made, that, since we're using the "standard" cron template we shouldn't mess with that.

It seems like this should be straightforward to implement:
Currently, we just pass time.Now() into the syncOne loop. The cron lib that k8s is using seems to work by just using times in the zone you care about. So, we could pull the timezone from the CronJob and pass that time with zone into the syncOne func.

//init the loc, needs error handling
//perhaps default to local if Timezone was invalid
loc, _ := time.LoadLocation(cronjob.Spec.Timezone)

//set timezone,  
now := time.Now().In(loc)

Also, I'm happy to try to implement this.

[mml]

I'm not the right person to review your PR, but I do have a few questions about semantics.

• What are the semantics when no timezone is specified?
• Does the implementation depend on the timezone being correctly configured on the controller host?
• When do we validate timezone legality? At object create/update time, or later?
• What happens if a timezone name was legal when the API object was created, but in the future no longer exists? This could happen because a name is removed (maybe a city or nation ceases to exist), or because the underlying tzdata package has changed to an older version.

[iterion]

If no timezone is defined it would default to the current behavior which would be to use the timezone of the host. I would guess in most cases this would be configured as UTC, but a user could really choose any timezone. As such, there is no greater dependency on timezone being correctly configured on the host as a result of this PR.

I currently just bail out and use the host's timezone if the user specified something invalid. Here, I'm leaning on golang's time.LoadLocation(str) method. Any string accepted by that function would be considered valid. I'm not currently validating this at create/update time, though it seems that would be a pretty easy thing to do.

As far as the last question, that one's a bit more undefined. Currently, and probably in the future, it would most likely fall back to scheduling the job based on the default time zone. I'm open to suggestions on how to handle this case.

[soltysh]

What happens if a timezone name was legal when the API object was created, but in the future no longer exists? This could happen because a name is removed (maybe a city or nation ceases to exist), or because the underlying tzdata package has changed to an older version.

My suggestion for that would be to fail job creation with an appropriate event. But frankly speaking I doubt this happens that often. I'll make sure to have this added in your implementation @iterion.