Issue #2778


Repository sync schedule moves based on timezone changes like daylight savings time.

Added by hyu about 5 years ago. Updated about 3 years ago.

Start date:
Due date:
Estimated time:
3. High
Platform Release:
Sprint Candidate:
Pulp 2


User runs sync plan daily on '10.00 -07:00'(PDT). When user switches back from the daily saving to PST (-08:00), the repository sync started 1 hour earlier (09:00 PST).

When I check the schedule time using pulp admin, I notice that the "-07:00" is included in the scheduled time so it doesn't affected by daylight saving.


pulp-admin --username admin --password <password> rpm repo sync schedules list --repo-id some_orgs-Red_Hat_Satellite_Capsule-Red_Hat_Satellite_Capsule_6_2_for_RHEL_7_Server_RPMs_x86_64

Schedule: 2017-05-29T00:00:00-07:00/PT1H
Id:       592b9eb1f7ecdd20717692c4
Enabled:  True
Next Run: 2017-05-29T07:00:00Z
Actions #1

Updated by bmbouter about 5 years ago

  • Description updated (diff)

What you are asking for is to have the schedules represented as a naive (non-timezone aware) datetime. Sometimes that is referred to as "local time" which means its the idea of 10AM regardless of if its PDT or PST for example. Pulp uses iso8601 to express time, and that standard allows for the expression of local time by leaving off timezone information[0].

Can you please show how this sync schedule was created?
Can you give an example that shows Pulp attaching timezone information even when it wasn't specified at schedule creation time?

I'm thinking that if the client specifies a timezone naive iso8601 expression that Pulp will do what you are asking for.


Actions #2

Updated by mhrivnak about 5 years ago

Pulp stores all times as UTC and expects all times provided through the API to also be UTC:

Most systems also have their clocks set to UTC. Determining what timezone is the "local" one can be challenging even if the system has the local timezone. As an example, the user's timezone may be different from the server's. It's also possible for servers to move from one timezone to another thanks to the miracles of "the cloud". So the least ambiguous thing to do is always represent times as UTC.

Actions #3

Updated by ttereshc about 5 years ago

  • Status changed from NEW to CLOSED - WONTFIX
  • Triaged changed from No to Yes

This issue is not expected to be fixed for Pulp 2.y.
To avoid it, please specify time in UTC as mentioned in comment by mhrivnak.

Actions #4

Updated by bmbouter about 5 years ago

  • Subject changed from Repository sync schedule doesn't consider daylight saving to Repository sync schedule moves based on timezone changes like daylight savings time.

I'm also not sure this is a Pulp bug at all if the datetime is expressed with a naive "local time". I'm rewriting the title to reflect what I think the user really wants.

Expressing this in UTC will cause the same issue the user is experiencing because 10am in PST and 10am in PDT are not the same UTC time. The user needs to not express it in UTC but with a non-timezone aware iso8601 which should be possible.

Actions #5

Updated by hyu about 5 years ago

The time is set by Satellite 6 when creating a sync plan. Satellite allows user to set their timezone, so I think it is probably not a good idea for satellite to set a naive "local time".

Actions #7

Updated by bmbouter about 5 years ago

I think any client (like Satellite) has the user set the Locale which does not change, but the timezone changes for that locale are handled automatically. So for daylight savings time in the US for example, the locale provides two timezones Eastern Daylight Time and Eastern Standard Time. The issue is that when a sync plan is submitted with an iso8601 formatted datetime that comes with a timezone, it is converted to UTC and stored as UTC. Then when the timezone changes say from EDT -> EST, the value of UTC does not change which causes the sync to run at an unexpected time.

As a workaround, the client (Satellite) can update the sync plans with the timezone change on the day it occurs. For example On Nov 5, the timezone in Raleigh will transition from EDT -> EST. The other option is to use "naive" times.

Actions #8

Updated by bmbouter over 4 years ago

  • Status changed from CLOSED - WONTFIX to CLOSED - NOTABUG

Changing to NOTABUG because the Pulp behaviors are correct based on the timezone data submitted by the user.

Actions #9

Updated by bmbouter about 3 years ago

  • Tags Pulp 2 added

Also available in: Atom PDF