Thread

I see you rolling your eyes. Yes, another thread about DST! 😊

I’ve read the docs. I’ve read forum threads like this. I’m still stuck.

I’m importing entries using DataGrab. Wait! It’s not a DataGrab issue. Please don’t dismiss me yet. 😊

Entries that have dates between now and the next DST change in March are fine. Entries that have dates after the next DST are off by an hour.

The data going into EE is correct. Once EE gets it’s mits on it, they’re off by an hour.

See the attached screen shot. The left side is a debug dump of the $data getting sent to EE. The right side is the entry once it has been created in EE.

I’m expecting the expiration date to be 12:00 AM, just like the data is telling it. Is there a way to tell EE to not adjust for DST and just use the dates it is getting?

This is the API call that is creating the entry.

this->api_channel_entries->submit_new_entry( 
      $this->channel_defaults["channel_id"], 
      $data )

Here are my localization settings:

// Localization preferences
        'server_timezone' => 'UM6',
        'server_offset' => FALSE,
        'time_format' => 'us',
        'daylight_savings' => 'n',
        'honor_entry_dst' => 'n',

I have turned off the member preference to allow localization override.

This is EE 2.3.1 build 20111017.

hi Jason,

How are you pulling entries into DataGrab (XML/RSS)? Can you attach to your reply a small set of entries that we can test with or if you prefer email me privately at john.donovan [at] ellislab.com

Hi John Henry,

We’re importing as a RSS feed.

I emailed you an xml file and the feed URL.

You can pretty much ignore all of the fields and just focus on the start time and end time fields.

<StartTime>01/13/2012 02:00:00 PM</StartTime>
<EndTime>01/13/2012 03:00:00 PM</EndTime>

We’re setting the entry_date to <StartTime> and expiration_date to <EndTime>.

Let me know what else I can do to help figure this out. I don’t mind getting my hands dirty.

By the way, take a close look at the event titled “Daylight Savings” on March 11. This is where the problem shows itself.

The <StartTime> is before DST switch over, so it gets imported correctly.

The <EndTime> is after the DST switch over and is off by an hour after import.

The entry_date and expiration_date fields for all events after March 11 are off by an hour.

Hi Jason,

// Localization preferences
      ‘server_timezone’ => ‘UM6’,
      ‘server_offset’ => FALSE,
      ‘time_format’ => ‘us’,
      ‘daylight_savings’ => ‘n’,
      ‘honor_entry_dst’ => ‘n’,

Where have you added these settings?

I found 2 threads here and here where we acknowledge there is issues with DST and are still working towards a more acceptable solution

Thanks John.

Those settings are in my bootstrap config file.

Is there a bug I can watch? I wrote some code to work around the issue for the time being, but need to undo that code once the bug is fixed.

If there’s not a bug I can open one.

Jason,

I searched throughout the bug tracker and found several DST bugs but none that are exactly the same as yours. In this case i would recommend opening a new I’ve filed a bug report for you on this issue. I encourage you to comment on that thread in order to keep informed of the status of the fix..

Sean

Hi Sean,

Did you open a new bug? That link didn’t point to a specific bug.

If not, I’m happy to open one.

Thanks.

Jason,

Not sure what happened there, but I’ve re-created the I’ve filed a bug report here.

Sean

Hi Jason,

Is there any chance you can share the code workaround you made? We’ve got the same issue and there doesn’t seem to be any update on the bug tracker. I suspect it ranks lower in priority with it relating to a third party add-on.

is there any update from EllisLab on this?

Hey Andrew,

Thank you for your question.

I will ask about it for you and see what I can do. I see that you added a comment to the bug already! Nice.

Cheers,

Andrew Weaver - the guy who developed DataGrab has added a fix to his module (http://brandnewbox.co.uk/forums/viewthread/701/) that forces the import to use the timezone settings in EE, rather than on the server. This seems to have fixed my particular issue, but I’m presuming the DST bugs will persist for some.

Hey Andrew Armitage,

Thank you letting us know!

If you need anything else, please just let me know by opening a new thread.

Cheers,