@@ -63,7 +63,7 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
63
63
## Summary
64
64
65
65
CronJob creates Jobs based on the schedule specified by the author, but the Time
66
- Zone used during the creation depens on where kube-controller-manager is running.
66
+ Zone used during the creation depends on where kube-controller-manager is running.
67
67
This proposal aims to extend CronJob resource with the ability for a user to
68
68
define the TimeZone when a Job should be created.
69
69
@@ -76,13 +76,13 @@ at the time was that introducing such functionality would require cluster operat
76
76
to manually include TimeZone database since golang did not have one.
77
77
Starting from [ golang 1.15] ( https://go.dev/doc/go1.15 ) ` time/tzdata ` package can
78
78
be embedded in the binary thus removing the requirement for external database.
79
- At that time the majority of the focus was towards [ moving CronJob to GA] ( https://github.com/kubernetes/enhancements/issues/19 )
79
+ At that time, the majority of the focus was towards [ moving CronJob to GA] ( https://github.com/kubernetes/enhancements/issues/19 ) ,
80
80
so the effort to support TimeZone was again delayed. Now that we have CronJob
81
81
fully GA-ed it's time to satisfy the original request.
82
82
83
83
### Goals
84
84
85
- - Add the field ` .spec.timeZone ` which allows specifying a valid TimeZone
85
+ - Add the field ` .spec.timeZone ` which allows specifying a valid TimeZone name
86
86
87
87
### Non-Goals
88
88
@@ -95,14 +95,14 @@ and make progress.
95
95
96
96
Add the field ` .spec.timeZone ` to the CronJob resource. The cronjob controller
97
97
will take the field into account when scheduling the next Job run. In case the
98
- field is not specified or is empty the controller will maitain the current
99
- behavior which is to rely on the time zone of the kube-controller-manager
98
+ field is not specified or is empty, the controller will maintain the current
99
+ behavior, which is to rely on the time zone of the kube-controller-manager
100
100
process.
101
101
102
102
### Notes/Constraints/Caveats (Optional)
103
103
104
- The current mechanism, which will still be the default behavior heavily relies
105
- on the time zone of the kube-controller-manager process which is hard for a
104
+ The current mechanism, which will still be the default behavior, heavily relies
105
+ on the time zone of the kube-controller-manager process, which is hard for a
106
106
regular user to figure out. Exposing an explicit field for setting a time zone
107
107
will allow CronJob authors to simplify the user experience when creating CronJobs.
108
108
@@ -125,20 +125,22 @@ CronJobs can be created per user.
125
125
126
126
### CronJob API
127
127
128
- The ` CronJobSpec ` structure is expanded with new ` TimeZone ` field which allows
128
+ The ` .spec ` for a CronJob is expanded with a new ` timeZone ` field which allows
129
129
specifying the name of the time zone to be used. Missing or empty value of the
130
130
field indicates the current behavior, which relies on the time zone of the
131
131
kube-controller-manager process.
132
132
133
+ In the API code, that looks like:
134
+
133
135
``` golang
134
136
135
137
type CronJobSpec struct {
136
138
137
- // The schedule in Cron format, see https://en.wikipedia.org/wiki/Cron.
138
- Schedule string
139
+ // The schedule in Cron format, see https://en.wikipedia.org/wiki/Cron.
140
+ Schedule string
139
141
140
- // Time zone for the above schedule
141
- TimeZone *string
142
+ // Time zone for the above schedule
143
+ TimeZone *string
142
144
143
145
}
144
146
```
@@ -149,7 +151,7 @@ golang timezone database.
149
151
### CronJob controller
150
152
151
153
CronJob controller will use non-nil, non-empty value from ` TimeZone ` field when
152
- parsing the schedule and during scheduling the next run time. Additionally the
154
+ parsing the schedule and during scheduling the next run time. Additionally, the
153
155
time zone will be reflected in the ` .status.lastSuccessfulTime ` and ` .status.lastScheduleTime ` .
154
156
In all other cases the controller will maintain the current behavior.
155
157
@@ -489,6 +491,9 @@ Why should this KEP _not_ be implemented?
489
491
490
492
## Alternatives
491
493
494
+ Another approach was to specify time zone as an offset to UTC, but using the
495
+ name instead seems more user friendly.
496
+
492
497
<!--
493
498
What other approaches did you consider, and why did you rule them out? These do
494
499
not need to be as detailed as the proposal, but should include enough
0 commit comments