Singularity Request - Timezone field (API) #1150
Conversation
| @@ -24,6 +25,7 @@ | |||
| private final Optional<String> schedule; | |||
| private final Optional<String> quartzSchedule; | |||
| private final Optional<ScheduleType> scheduleType; | |||
| private final Optional<TimeZone> scheduledTimeZone; | |||
There was a problem hiding this comment.
i'd keep the naming consistent and go with scheduleTimeZone
|
Thanks for the PR! Could you add a unittest that exercises this feature? It would also be good to verify that setting a bogus timezone fails in an appropriate way (i.e. you get a meaningful error message back from the API) |
…kson from auto-validating); removed unnecessary memoization
…propriately to handle a string instead of a timezone
US/Eastern and GMT are daylight-savings-respecting timezone codes, but EST is not, and may lead to confusion if used. This error code tries to suggest better alternatives.
ghost
self-assigned this
Having trouble getting a PENDING task after POSTing two scheduled tasks. Fix will follow in time.
ghost
removed their assignment
Two primary issues contributed to this test's delay: - 2099 is the last valid year in Quartz 1, and - getPendingTaskIds() returns in random order. The latter was made clear immediately, but the former was elusive; getNextRunAt() simply returned a null pointer, despite Quartz admitting that the cron expression was valid.
| @@ -9,6 +9,9 @@ | |||
| import java.util.Set; | |||
| import java.util.concurrent.TimeUnit; | |||
|
|
|||
| import javax.ws.rs.WebApplicationException; | |||
|
|
|||
| import org.apache.commons.jexl2.UnifiedJEXL.Exception; | |||
There was a problem hiding this comment.
don't think this import is used anywhere
There was a problem hiding this comment.
The WebApplicationException is used, but yes I don't believe the JEXL one is.
| } | ||
|
|
||
| // GMT happens first, so EST is a larger timestamp | ||
| Assert.assertEquals(nextRunEST - nextRunGMT, fiveHoursInMilliseconds); |
There was a problem hiding this comment.
Consider using TimeUnit.HOURS.toMillis() instead
|
@Calvinp has this field been added to the UI in the rewrite? If not can we add it? |
|
It has been, yes. See #1182 |
|
Going to merge this since UI field has been added in the rewrite |
This PR extends the Singularity Request code to accept an optional (string) timezone through the API. Local testing passed.
Still needs frontend changes to make the timezones accessible to the end user.
/cc @ssalinas @Calvinp
/fixes #1002