Daily Plan: Incorrect DST handling when period_begin is not midnight (period_begin != 00:00)

Current Situation

• For time zones that observe Daylight Saving Time (DST), clocks are moved forward in spring and back in autumn.
• When period_begin is configured with a value other than midnight (for example, 06:00), the Daily Plan can calculate incorrect start times during and after the DST transition within the Daily Plan day defined by period_begin.

Desired Behavior

• The configured period_begin should only define the beginning of the 24-hour Daily Plan day.
• The DST transition should be handled correctly and should not affect start times outside the actual DST switch-over period within the Daily Plan day defined by period_begin.

Test Instructions

• Use default Daily Plan setting: period_begin = 00:00:00 (midnight)
  • Use different Daily Plan time zones:
    • Default UTC
    • A time zone west of UTC (e.g. America/New_York)
    • A time zone east of UTC (e.g. Europe/Berlin)
  • Test Daily Plan on winter DST (fall back) and summer DST (spring forward).
  • Use different Schedule time zones
  • Use single and cyclic (repeat) start times:
    • Start times before, during, and after the DST time change slot
    • For cyclic: use repeat intervals that cross the DST gap / overlap (e.g. 00:00-03:30, repeat = 00:15:00)
  • Verification methods
    • Daily Plan GUI
      • Check displayed start times
      • Note: Cyclic orders do NOT show individual entries in the GUI, use other methods for cyclic verification
    • Logs (Service Daily Plan)
      • Set ServiceDailyPlanLogLevel = DEBUG in resources/joc/log4j2.xml
      • Log file: service-dailyplan-debug.log
      • Check for zoned start times and UTC conversions
    • Database
      • Table: DPL_ORDERS.PLANNED_START
      • Check stored UTC timestamps and number of entries
  • Expected results
    • Day before and after DST - should not be affected (normal behavior)
    • Winter DST (fall back)
      • GUI shows zoned times normally
      • In logs or database: a UTC gap of about 1 hour should be visible
      • Reason: on winter DST, the zoned time exists twice – as summer time and as winter time. Using only one of them (without the offset) leads to a UTC gap of about 1 hour.
        • Example (Europe/Berlin, 2026-10-25):
          • 02:00 +0200 (summer time) -> 00:00 UTC
          • 02:00 +0100 (winter time) -> 01:00 UTC
          • Using only 02:00 (without offset) means one of these UTC times is lost -> results in a UTC gap (e.g. 01:00-01:45 UTC missing).
    • Summer DST (spring forward)
      • GUI shows zoned times shifted to the later hour (e.g. 03:00 instead of 02:00)
      • In logs or database: no UTC gaps should be visible
      • Reason: on summer DST, the clock jumps forward by one hour - the zoned time (e.g. 02:00) does not exist. A start time scheduled for 02:00 will be executed at 03:00 instead (the next valid time).
        • Example (Europe/Berlin, 2027-03-28):
          • An order scheduled for 02:00 (Berlin time) cannot run because 02:00 does not exist
          • It will be generated at 03:00 (Berlin time) instead
• Repeat tests
  • Repeat all tests with Daily Plan setting: period_begin != 00:00:00 (e.g. 06:00:00, 22:00:00, ...)