Home/ Questions/Q 8378495
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T15:56:32+00:00

Very strange error indeed. I have an item that clones itself every month, setting

  • 0

Very strange error indeed. I have an item that clones itself every month, setting the next object to have a scheduled_on date, + 1.months in the future.

But then this happened :

Sun, 01 Apr 2012 16:00:00 PDT -07:00
Tue, 01 May 2012 16:00:00 PDT -07:00
Fri, 01 Jun 2012 16:00:00 PDT -07:00
Sun, 01 Jul 2012 16:00:00 PDT -07:00
Wed, 01 Aug 2012 16:00:00 PDT -07:00
Fri, 31 Aug 2012 17:00:00 PDT -07:00 # <--- What in the..

The code :

def clone_object
  objects = []

  Time.zone = account.timezone
  Chronic.time_class = Time.zone

  now = last_scheduled_on.to_time # <- this would have been Wed, 01 Aug 2012 16:00:00 PDT -07:00

  new_date = now + 1.months

  new_schedule = Time.zone.parse new_date.strftime('%Y-%m-%d' + ' ' + original_scheduled_on.strftime('%H:%M:%S'))

  objects << clone!(:scheduled_on => new_schedule, :recurring_job_id => id)

end

That is a very truncated version of the actual code. But it includes all the parts that I are reasonably affecting this issue.

So the question is.. how could that error could have possibly occurred?

Update

I’m pretty sure this is timezone related.

Here’s the Dates in UTC: 

In UTC :

Sun, 01 Apr 2012 23:00:00 UTC +00:00
Tue, 01 May 2012 23:00:00 UTC +00:00
Fri, 01 Jun 2012 23:00:00 UTC +00:00
Sun, 01 Jul 2012 23:00:00 UTC +00:00
Wed, 01 Aug 2012 23:00:00 UTC +00:00
Sat, 01 Sep 2012 00:00:00 UTC +00:00
Sun, 30 Sep 2012 23:00:00 UTC +00:00

Here they are converted to Pacific :

In Pacific

Sun, 01 Apr 2012 16:00:00 PDT -07:00
Tue, 01 May 2012 16:00:00 PDT -07:00
Fri, 01 Jun 2012 16:00:00 PDT -07:00
Sun, 01 Jul 2012 16:00:00 PDT -07:00
Wed, 01 Aug 2012 16:00:00 PDT -07:00
Fri, 31 Aug 2012 17:00:00 PDT -07:00
Sun, 30 Sep 2012 16:00:00 PDT -07:00

I also noted that the code I put here in not accurate to my server. The server has the Time.zone set to the last job and not the account’s timezone. This means ( or at least I think it means ), that the timezone is then floating and dynamic. But that bothers me also because Daylight savings time in California does not switch over until November, not September.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The reason this is occurring is because when you add two DateTime’s, the DateTime object will add by number of days and discredit timezones.

    When you add two Time objects together, they will add by the hour, and include any timezone differences.

    The hour difference occurred specifically because two DateTime’s were added together that transgressed over a Timezone change. The time then is saved to the database in UTC as the same number despite the fact that when they are later parsed in their respective timezone’s, they will be offset by one hour.

    • 0