Thread

Are you still on 1.6.6, or did you manage to upgrade at some point?

Are you still on 1.6.6, or did you manage to upgrade at some point?

Still on 1.6.6. I tweaked several core EE files on this installation, and didn’t document the changes. I’ve been avoiding upgrading because I can’t think of a clean way to do it. I think I’ll need to install the latest version into a separate directory, then run a giant diff against my current install to see which files have been modified.

Does the latest version have any patches related to my problem?

I think I’ll need to install the latest version into a separate directory, then run a giant diff against my current install to see which files have been modified.

In the absence of “hacking” notes, this might be one way to do it, yes.

Does the latest version have any patches related to my problem?

There were numerous bugfixes and improvements. There probably were changes to the whole “localization” complex as well, but in any case we’ll need to be on the same page in terms of code if we’re to get to the bottom of this. None of us are running this version any more.

I think I’ll need to install the latest version into a separate directory, then run a giant diff against my current install to see which files have been modified.

There are too many changes in 1.6.8 for this to work. I’d like to try the same thing by diffing against a clean install of 1.6.6 in a different folder. Where can I redownload 1.6.6?

Hi, knite - we do not make older version of the software available, only the latest version of 1.x is available for download.

CP Home ›  Admin ›  System Preferences ›  Localization Settings

UTC -6 (Central)
No offset
USA
DST Yes
Honor DST on each entry Yes

CP Home ›  My Account ›  Localization Settings

UTC -6 (Central)
DST No
USA
English

CP Home ›  My Account ›  Member Administration

Super Admin
Include in Publish list No
Use Member’s localization settings as site default No

I have the exact same settings as knite above except DST under system localization settings is currently set to No (DST doesn’t start until this Sunday here).  I’m on EE 1.6.8.  The server is in the same time zone (CST US) and observes DST during the normal US CST timeframe.

With an event that happens after DST goes into effect, regardless if I use an SAEF or the Control panel to create an entry the times go back 1hr.

Worse when that entry is edited, the times go back yet another hour!  This decrement continues for each edit, basically because it pulls the time which was already decremented and then decrements it again on submission.

These are on the Entry Date and Expiration Date.  This happens regardless if I have DST enabled for this entry or not.

I have a custom date field as well.  If I leave it to localization, it decrements with the others.  With DST for entry checked, it does not decrement (i.e. it stays correct).  If I set it to ‘Fixed’ and do not check DST for entry, it stays right.  Here’s the really weird thing,  If I set the custom date field to Fixed AND check DST for entry, the custom date field decrements 2hrs every submit.

Weird thing is we ‘spring forward with DST’, not back and hour so even with the complexity, I’m not understanding the decrementing times.

If I disable Honor DST for Entry under Sys Pref/Localization Prefs, both the entry and expire dates continue to decrement on submission and every edit.  The custom date field doesn’t change regardless if its set to localized or fixed.

I have a feeling to resolve this, I’m going to have to rebuild the weblog to have two more custom dates to replace the built-in entry and expire, set them to fixed and just disable all localization settings.

Taking note from one of Robin’s earlier recommendation (from a post I’m too lazy to go find to reference), turn everything off, used fixed and then do a offset manually (I guess you could cron it) during DST.

I understand this is really complicated code wise in relation to entries, user, server, etc.  It would be really nice to be able to truely override all localization settings and force everything to to be either fixed or live at the server time… then we could customize the page, say with a format ‘tag’ for date that will process that time based on other criteria, such as users settings, specific weblog settings, etc.  At the very least being able to make the entry/expire built-in fields to act as fixed rather than always localized.

OK… should have tested this first.  Have the plug. BlindDate v1.3.0 installed (very helpful ext).  If I disable this, the quirky working of the entry and expire dates stops.

However, the custom date field still has it’s odd behavior.  With Honor Entry DST settings enabled, setting the entry DST active, and then the custom date field set to fixed, this value still decrements by 2 hrs.

leejb,

Double check that these two settings match:

CP Home ›  Admin ›  System Preferences ›  Localization Settings
CP Home ›  My Account ›  Localization Settings

...and then create a new entry (with BlindDate disabled, of course).  Do the custom date fields still exhibit that behavior?

Sorry for the response delay. (Note: on the BlindDate plug:  I tried the below with it enabled and it only effected Test2, so it seems (to me) it only has an issue when the date you are submitting is not in the same DST state as the current time/system time.  Do to time I did not mess with the DST setting in the local account)

Setting Sys. localization to DST Active:Honor DST Active:CST, then My Account localization settings DST Active:CST (Previously noted my local account was set to DST not active).  *note: Admin ›  Members and Groups ›  Membership Preferences > “Allow members to set their own localization pref.” option is set to No.

Test1:
If I create a 2 new entries, both within the same DST period, entry/expire are set for 4/2 1pm/2pm and the entries DST setting is Active.  Entry1 custom date set to fixed, Entry2 set to localized, both 4/1 12:56pm.  After submit all dates stay correct.  When I turn DST off in the server localization settings, Entry1’s fixed custom field decreases by 2hours (10:56am) while Entry2’s localized field goes back by only 1hour (11:56pm).

Test2:
Same as above, except date is in next DST period (i.e. 11/8)  Same result.

I set My Account’s DST to unchecked and redid Test1 and 2 again, but that cause no change in results.

Which build are you on, leejb?

DST begins and ends on different dates in different locations, so EE does not infer anything regarding DST by the date.  You’ll need to manually tell EE whether your location is observing DST or not.

Also, have you done these tests when logged out?

v1.6.8:20090723

As far as them being displayed, the times are the same regardless if the viewer is anon or logged in.  I’ve tried with two different accounts on the tests listed above, but both are set to CST and I followed the DST settings as listed in the tests.

Hi leejb, a few other things I’d suggest:

1. Go ahead and update to the latest build.
2. Make sure you’re doing all testing with the BlindDate plugin completely disabled.
3. Under Admin > System Preferences > Localization Settings, make sure Server Offset is 0.

Let us know how that goes.

Will do, but will be delayed as I will have to schedule a maint. window for it, probably a week or two.

Will removed the files for plug-in in addition to the disabling.  Offset was blank, will try with setting to ‘0’

No problem.  We’ll be here :cheese:

FYI, I’ve been experiencing the same bug leejb mentions above where if the entry is after the next time change the entry date jumps an hour every time you save the entry.  I’ve disabled the Blind Date extension and the date has stopped jumping.