Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Singularity Request - Timezone field (API) #1150

Merged
merged 14 commits into from Aug 5, 2016

Conversation

ghost
Copy link

@ghost ghost commented Jul 15, 2016

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

@@ -24,6 +25,7 @@
private final Optional<String> schedule;
private final Optional<String> quartzSchedule;
private final Optional<ScheduleType> scheduleType;
private final Optional<TimeZone> scheduledTimeZone;
Copy link
Contributor

@tpetr tpetr Jul 15, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'd keep the naming consistent and go with scheduleTimeZone

@tpetr
Copy link
Contributor

tpetr commented Jul 15, 2016

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)

MattCCS added 5 commits Jul 15, 2016
…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 ghost self-assigned this Jul 18, 2016
MattCCS added 2 commits Jul 18, 2016
Having trouble getting a PENDING task after POSTing two scheduled tasks.
Fix will follow in time.
@ghost ghost removed their assignment Jul 19, 2016
MattCCS added 2 commits Jul 19, 2016
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;
Copy link
Member

@ssalinas ssalinas Jul 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't think this import is used anywhere

Copy link
Contributor

@MattCCS MattCCS Jul 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);
Copy link
Contributor

@tpetr tpetr Jul 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider using TimeUnit.HOURS.toMillis() instead

@ssalinas ssalinas modified the milestone: 0.10.0 Jul 29, 2016
@ssalinas
Copy link
Member

ssalinas commented Aug 3, 2016

@Calvinp has this field been added to the UI in the rewrite? If not can we add it?

@Calvinp
Copy link
Contributor

Calvinp commented Aug 4, 2016

It has been, yes. See #1182

@ssalinas
Copy link
Member

ssalinas commented Aug 5, 2016

Going to merge this since UI field has been added in the rewrite

@ssalinas ssalinas merged commit c683d70 into master Aug 5, 2016
1 of 2 checks passed
@ssalinas ssalinas deleted the singularity_request_timezone branch Aug 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Should be able to specify TZ for SCHEDULED requests
4 participants