apache/dolphinscheduler · error · ServiceException

SCHEDULE_START_TIME_END_TIME_SAME

SCHEDULE_START_TIME_END_TIME_SAME

Error message

SCHEDULE_START_TIME_END_TIME_SAME: start time must not be the same as end time

What it means

DolphinScheduler throws SCHEDULE_START_TIME_END_TIME_SAME when a schedule is created whose start time and end time resolve to the same second (DateUtils.differSec(...) == 0). A schedule with zero duration is meaningless for the quartz-based scheduler, so insertSchedule rejects it before persisting. The check also implicitly covers null start/end times, which fail parsing/comparison.

Source

Thrown at dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/SchedulerServiceImpl.java:159

                    workflowDefinitionCode);
            throw new ServiceException(Status.SCHEDULE_ALREADY_EXISTS, workflowDefinitionCode,
                    scheduleExists.getId());
        }

        Schedule scheduleObj = new Schedule();
        Date now = new Date();

        tenantExistValidator.validate(tenantCode);

        scheduleObj.setTenantCode(tenantCode);
        scheduleObj.setProjectName(project.getName());
        scheduleObj.setWorkflowDefinitionCode(workflowDefinitionCode);
        scheduleObj.setWorkflowDefinitionName(workflowDefinition.getName());

        ScheduleParam scheduleParam = JSONUtils.parseObject(schedule, ScheduleParam.class);
        if (DateUtils.differSec(scheduleParam.getStartTime(), scheduleParam.getEndTime()) == 0) {
            log.warn("The start time must not be the same as the end or time can not be null.");
            throw new ServiceException(Status.SCHEDULE_START_TIME_END_TIME_SAME);
        }
        if (scheduleParam.getStartTime().getTime() > scheduleParam.getEndTime().getTime()) {
            log.warn("The start time must smaller than end time");
            throw new ServiceException(Status.START_TIME_BIGGER_THAN_END_TIME_ERROR);
        }

        scheduleObj.setStartTime(scheduleParam.getStartTime());
        scheduleObj.setEndTime(scheduleParam.getEndTime());
        if (!CronUtils.isValidExpression(scheduleParam.getCrontab())) {
            log.error("Schedule crontab verify failure, crontab:{}.", scheduleParam.getCrontab());
            throw new ServiceException(Status.REQUEST_PARAMS_NOT_VALID_ERROR, scheduleParam.getCrontab());
        }
        scheduleObj.setCrontab(scheduleParam.getCrontab());
        validateMissedFirePolicy(scheduleParam);
        scheduleObj.setMissedFirePolicy(scheduleParam.getMissedFirePolicy());
        scheduleObj.setTimezoneId(scheduleParam.getTimezoneId());
        scheduleObj.setWarningType(warningType);
        scheduleObj.setWarningGroupId(warningGroupId);

View on GitHub (pinned to 02eac45a1b)

Solutions

Provide an endTime strictly later than startTime (at least 1 second apart) in the schedule JSON.
Validate the parsed ScheduleParam client-side before calling the API: if (DateUtils.differSec(start, end) == 0) reject.
If null times caused the parse to yield equal values, include explicit, non-null startTime and endTime strings in 'yyyy-MM-dd HH:mm:ss' format.

Example fix

// before
String schedule = "{\"startTime\":\"2026-09-01 10:00:00\",\"endTime\":\"2026-09-01 10:00:00\",\"crontab\":\"0 0 0 * * ? *\"}";
// after
String schedule = "{\"startTime\":\"2026-09-01 10:00:00\",\"endTime\":\"2026-09-01 11:00:00\",\"crontab\":\"0 0 0 * * ? *\"}";

Defensive patterns

Strategy: validation

Validate before calling

Date start = sdf.parse(param.getStartTime());
Date end = sdf.parse(param.getEndTime());
if (start == null || end == null || DateUtils.differSec(start, end) == 0) {
    throw new IllegalArgumentException("startTime and endTime must differ by at least 1 second");
}

Try / catch

try { schedulerService.insertSchedule(...); } catch (ServiceException e) { if (e.getCode() == Status.SCHEDULE_START_TIME_END_TIME_SAME) { /* fix times and retry or surface to user */ } }

Prevention

Always set endTime after startTime in schedule forms; validate before submit
Include explicit 'yyyy-MM-dd HH:mm:ss' timestamps, never rely on defaults
Unit-test schedule payloads with a differSec(start,end) > 0 assertion

When it happens

Trigger: Calling POST /projects/{projectCode}/schedule (or SchedulerService.insertSchedule) with a JSON `schedule` body where ScheduleParam.startTime equals Schedule.endTime, e.g. {"startTime":"2026-09-01 10:00:00","endTime":"2026-09-01 10:00:00","crontab":"0 0 0 * * ? *"}.

Common situations: UI form defaults that prefill identical start/end timestamps; API scripts that template the same value into both fields; timezone conversion collapsing distinct local times to the same instant; forgetting to update endTime after editing startTime.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

AI-assisted analysis of apache/dolphinscheduler@02eac45a1b (2026-09-06). Data as JSON: /api/errors/83fea50543d1ab8e. Report an issue: GitHub.