JS7 JobScheduler

Space shortcuts

Page tree

Introduction

Time zone names are specified according to the List of tz database time zones.

JS7 supports time zones at a number of levels:

  • JS7 Products
    • JOC Cockpit, Controller and Agents can be operated in different time zones. Time zones are preset by the operating system.
    • This includes running a number of Agents in different time zones.
  • Scheduling Objects
    • Orders are scheduled for a point in time calculated for the given time zone by the orders' JS7 - Schedules.
    • The time zone of the workflow is taken account of when the JS7 - Admission Times for Jobs and cycles from the JS7 - Cycle Instruction are calculated.
    • The JS7 - Daily Plan considers the Daily Plan time zone. A Daily Plan does not necessarily have to span midnight to midnight, instead the Daily Plan can use any hour of the day as the starting point for its 24 hours period.
      • The Daily Plan's time zone is taken account of in both the start of the Daily Plan period and the point in time when the Daily Plan is calculated.
      • Cyclic workflows that make use of the JS7 - Cycle Instruction take account of the workflow's time zone.
  • Graphical User Interface (GUI)
    • Any dates and times that are displayed in the GUI are converted to the time zone specified from the user's profile.
      • This applies to order start dates, job admission times, entries of the JS7 - History etc.
      • This also applies to timestamps of order logs and task logs that are executed on Agents in different time zones. Users can choose from their user profile settings if they prefer to be presented with original log timestamps or if they prefer to have timestamps converted to the time zone specified in the user profile.
    • When adding orders by the GUI, then the time zone of the order's start date is specified.
    • When posting notices to JS7 - Notice Boards then the time zone for the notice's lifetime is specified.
    • Any time zone applied by the GUI by default is populated from the user profile's time zone setting and can be modified by the user.

Time zone changes include:

  • changes for individual countries due to government decisions. This also applies to changes to the date and time of daylight saving time,
  • Note that such changes can occur at short notice and therefore might not be reflected in the time zone database that ships with an earlier JS7 release.
  • Consider updating JS7 at a regular basis in order to receive up-to-date time zone databases.

JS7 Products

The JS7 Controller, Agent and JOC Cockpit use the time zone specified by the operating system by default.

Controller

The Controller makes use of the time zone reported by the operating system:

  • The Controller forwards dates to JOC Cockpit in UTC time and in case of JS7 - Order State Transitions with Agents, it adds the Agent's time zone if applicable.
  • The timestamps of entries in the Controller's log files are determined from the operating system time zone. This can be modified with the Log4j2 configuration file, see JS7 - Log Rotation.

The Controller start script provides environment variables that can be used in Shell jobs:

Agent

The Agent makes use of the time zone reported by the operating system:

  • The timestamps of entries in the Agent's log files are determined from the operating system time zone. This can be modified with the Log4j2 configuration file, see JS7 - Log Rotation.

The Agent start script provides environment variables that can be used in Shell jobs:

  • JS7_AGENT_TZ indicates the Agent's time zone. For the list of available TZ time zone values see https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.
  • JS7_SCHEDULED_DATE indicates the date an order is scheduled for and includes the offset of the Agent's time zone to UTC, e.g. 2020-12-03 09:13:59+0100.
  • JS7_SCHEDULED_YEAR, JS7_SCHEDULED_MONTH, JS7_SCHEDULED_DAY, JS7_SCHEDULED_HOUR, JS7_SCHEDULED_MINUTE, JS7_SCHEDULED_SECOND are indicated in the Agent's time zone.
  • JS7_JOBSTART_DATE indicates the date a job is started in the Agent's time zone and includes the offset of the Agent's time zone to UTC e.g. 2020-12-03 09:13:59+0100.
  • JS7_JOBSTART_YEAR, JS7_JOBSTART_MONTH, JS7_JOBSTART_DAY, JS7_JOBSTART_HOUR, JS7_JOBSTART_MINUTE, JS7_JOBSTART_SECOND are indicated in the Agent's time zone.

Note:

  • Note that the offset of the Agent's time zone to UTC can change during Daylight Saving Change. The offset to UTC indicated by the above environment variables is calculated at the point in time when a job starts. Jobs sensitive to Daylight Saving Changes should take account of the fact that such changes can occur during job execution.

JOC Cockpit

The JOC Cockpit does not use the time zone reported by the operating system for the following purposes:

  • the JOC Cockpit switches its Java Virtual Machine to the UTC time zone. This behavior is required to guarantee consistent database transactions that are not affected by Daylight Saving Change.
  • the JOC Cockpit Web Services perform date calculations in the UTC time zone.

By default, the JOC Cockpit makes use of the operating system time zone when writing timestamps to log files. Users can modify the time zone for log timestamps, see JS7 - Log Rotation.

Time Zone Support by Scheduling Objects

Workflows

Workflows are specified with a time zone that is used to calculate JS7 - Admission Times for Jobs and cycles from the JS7 - Cycle Instruction:


The time zone setting is applied to Admission Times of jobs in the workflow:

Timed Orders from Schedules

When using JS7 - Schedules to create orders then the schedule is specified with a time zone that by default is populated from the user profile's time zone.

Ad hoc Orders from User Intervention

When manually adding orders to a workflow for a particular date then the time zone is preset from the user profile's time zone like this:


Note: If the option "Now" is used then the order starts immediately independently of the user's time zone setting. 

File Orders

JS7 - File Watching allows to create orders from incoming files. Such file orders carry the creation date with the Order ID. Time zones can be specified individually per File Order Source to allow assignment to the related Daily Plan date.

Daily Plan Service

The Daily Plan Settings take account of the time zone for the start of the 24 hours' period of the Daily Plan and for the point in time when the Daily Plan is calculated, see JS7 - Daily Plan Service.

Cleanup Service

The JS7 - Cleanup Service purges older entries in the database. Settings for the Cleanup Service use a time zone specification like this:


Time Zone Support by the Graphical User Interface

User Profile

The user profile is populated with the browser's time zone setting by default. Users are free to choose a different time zone. Any dates and times visible with JOC Cockpit are converted to the user profile's time zone.


Note:

  • Changes to the user profile's time zone do not modify the time zones specified with scheduling objects. Instead, such changes are used to convert any visible dates to the user profile's time zone.

For example, when modifying the original time zone from Europe/Berlin to America/Sao_Paulo then dates such as the system time are moved 5 hours back during European summer time.

Dashboard

The JS7 - Dashboard makes use of the user profile's time zone setting for any areas related to dates:


Note:

  • The system time is converted to the user's current time zone.
  • The widgets for current Orders, for the History and for the Daily Plan calculate their date range based on the user's current time zone.
  • The start times of Controller instances are converted to the user's current time zone.

Orders Overview

The date range for the selection of orders in this view takes account of the user's current time zone setting:


Daily Plan View

The JS7 - Daily Plan converts planned start times according to the user's current time zone setting:


Notes:

  • If the JS7 - Daily Plan Service is configured for a 24 hours' period that does not start at midnight of the user's current time zone, then orders for a Daily Plan date selected from the calendar widget might be displayed with planned start dates for the previous or for the next day. Users who consider this being confusing should align their Daily Plan time zone with time zones used in schedules.
  • If a schedule's time zone is different from the Daily Plan time zone, then 
    • orders will be assigned the Daily Plan date matching the start time specified without consideration of the schedule's time zone.
    • orders will start at the point in time specified by their start time considering the schedule's time zone.
  • This will result in the Daily Plan view showing orders for the same Daily Plan date including start times of -14 hours and +12 hours in addition to the 24 hours' Daily Plan period. Most surprisingly for some users, a day is not 24 hours long, but can span up to 50 hours. The period of a day always is 24 hours long as it depends on earth's rotation. However, for any given time zone there is a 50 hours' coverage to include all possible times around the planet.

Daylight Saving Changes

Changes to Daylight Saving can happen at different points in time for individual JS7 products, if the JOC Cockpit, Controller and Agents are operated in different time zones.

  • Some time zones know of Daiylight Saving, some don't.
  • Times zone using Daylight Saving use indivdual dates and hours for switch to and from summertime 

JOC Cockpit

  • The GUI makes use of the time zone that is in place with the user's device and JS7 - Profiles - Preferences.
  • When the user's clock is moved forth or back then this is immediately reflected with the GUI. Consider that for example the Daily Plan widget in the JS7 - Dashboard view will display orders in the categories of today etc. depending on the user's current time. This similarly applies to any JOC Cockpit views.
  • The JS7 - History will display results like this:
    • If the clock is moved forward, for example from 2am to 3am, then a task that starts at 1.55am and that runs for 10 minutes will terminate at 3.05am. The duration is reported being 10 minutes.
    • If the clock is moved back, for example from 3am to 2am then a task that starts at 2:55am and that runs for 10 minutes will terminate at 2:05am.
  • Log output of orders and tasks indicates the switch of daylight saving with timestamps in the log output.

Controller

The Controller is not affected by Daylight Saving Changes applied to log output for orders and tasks:

  • The Controller calculates dates and times in UTC that does not know of Daylight Saving.
  • The Controller is not involved in calculation of timestamps reported from Agents for log output of orders and tasks.

By default the Controller's own log files contain timestamps in the server's time zone as determined by the Controller Start Script.

  • The Controller Start Script applies the server's time zone as reported by the operating system to Java. If a server time zone is not set then it will fall back to the UTC time zone.
  • The Controller Start Script provides the JS7_CONTROLLER_TZ environment variable to indicate the time zone in use.

By default the Controller's Log4j configuration makes use of the JS7_CONTROLLER_TZ environment variable and calculates timestamps accordingly. This includes reflecting Daylight Saving Changes for timestamps in the Controller's log output if indicated by the time zone. For details see JS7 - Log Rotation.

Agent

The Agent keeps track of timestamps created for log output of orders and tasks as follows:

  • The Agent runs in its server's time zone and applies Daylight Saving Changes accordingly.
  • Log output of orders and tasks immediately reflects changes to the server's time.

By default, the Agent's log files contain timestamps in the server's time zone as determined by the Agent Start Script.

  • The Agent Start Script applies the server's time zone as reported by the operating system to Java. If a server time zone is not set, then it will fall back to the UTC time zone.
  • The Agent Start Script provides the JS7_AGENT_TZ environment variable to indicate the time zone in use.

By default the Agent's Log4j configuration makes use of the JS7_AGENT_TZ environment variable and applies timestamps accordingly. This includes reflecting Daylight Saving Changes for timestamps in the Agent's log output if indicated by the time zone. For details see JS7 - Log Rotation.

Orders

If an order is scheduled for a point in time when the clock is moved forward, then this point in time does not exist and the order will be executed one hour later. For example, a start time of 2:30am in the CET/CEST time zone does not exist for the hour in which switching to summertime is performed. Instead, the order will be started at 3.30am.

If an order is scheduled for a point in time when the clock is moved back, then this point in time exists twice. However, the order will be executed once only.

The same applies to cyclic orders that cover a period during which the clock is moved forward or back.

Further Resources

Find information about the behavior of individual features with Daylight Saving Changes from the following articles:



  • No labels