Symphony.

I'm running into a bizarre issue with the Date field. To recreate:

1. create a new entry
2. enter a date (for example 2012-01-19 00:00)
3. observe that the Date field now shows "2012-01-1 00:00", no matter what date was entered
4. load the entry's page on the frontend
5. observe that the correct date is shown

So basically the backend entry edit page will correctly save/update an entry's date, it is showing incorrect dates on the edit page after saving changes. Also, the entries table shows these incorrect dates.

What is even more bizarre, if I go back to the entry edit page and hit 'Save Changes' without making any changes, the value shown in the Date field changes! If I hit 'Save Changes' again, it shows yet another date (unfortunately also updating the entry's date with whatever incorrect value appeared). My guess is that it's fetching dates from other entries. This is causing some concern with my colleague who is doing a lot of data entry/cleaning at the moment.

I don't know if it matters, but I'm using the date format o-m-N H:i (for ISO conformant dates).

I've had some similar strangeness with the Date field lately. When I save an entry from the front-end it will repeat back the correct date. But then I check the entry on the back-end, it lists it as the day before. Very strange indeed.

Does it have to do with what the server time is set for?

Yeah, that sounds somewhat similar, but the Date that is shown to me after saving seems to more random, jumping all over the place (but never in the future). I think it's fetching Dates from other entries...

Are your system date and time settings correct in config.php?

And are you running 2.2.5? The bug you are describing is #863 and it was fixed in 2.2.5.

If you are running 2.2.5, what's your PHP/server setup?

If you have even more free time, would you mind installing Symphony Tests, running the two date tests and posting the results in Pastie or Gist?

Ours is 2.2.4, I will update soon.

OK, I'm running v2.2.3 so it's probably issue #863. I will update and verify (and will make sure to search the github issue tracker in addition to the forums when I run into problems like this in the future).

Thanks, y'all rock!

Ooh, and I'll check out Symphony Tests, wasn't aware that existed...

OK, I updated to 2.2.5 and am still observing this strange date field behavior. I will try to run through what's happening to aid troubleshooting:

Create a new record, specify a date of '2012-01-21 00:00'

Press Save Changes.

Observe that the entry's date field now shows '2012-01-6 00:00'.

Open up the entries list for this section, and observe that it shows '2012-01-06 00:00' also in the entries list.

Change the date back to '2012-01-21 00:00', hit Save Changes, note that the date in both the entry and entry list shows '2012-01-6 00:00'.

Change the date back to '2012-01-23 00:00', hit Save Changes, note that the date in both the entry and entry list shows '2012-01-1 00:00'.

Press 'Save Changes' without editing the Date field (currently '2012-01-1 00:00'). Note that the Date field then shows '2011-01-7 00:00'.

Repeatedly press 'Save Changes' without making any edits. This is the sequence of dates that appears:

2011-01-5 00:00
2011-01-3 00:00
2011-01-1 00:00
2010-01-6 00:00
2010-01-3 00:00
2009-01-7 00:00
2009-01-3 00:00
2009-01-6 00:00
2009-01-2 00:00
2009-01-1 00:00
2009-01-4 00:00
2009-01-7 00:00
2009-01-3 00:00
2009-01-6 00:00
2009-01-2 00:00
2009-01-5 00:00

(If I edit the hours, those changes remain):

2009-01-1 15:00
2009-01-4 15:00

etc...

Here's my server setup (via phpinfo()):

PHP: PHP Version 5.3.2-1ubuntu4.9
Server: Linux vm131.gsc.wustl.edu 2.6.32-27-server #49-Ubuntu SMP Thu Dec 2 02:05:21 UTC 2010 x86_64

I ran all the date/time related tests from the Symphony Tests extension, which all passed:

https://gist.github.com/1664417

I'm thinking about switching out the default Date field for Nils' Date and Time extension to see if that shows the same behavior. Would that help?

Thanks for your time!

Thanks for the gist.

Can you post the ###### REGION ##### block from manifest/config.php? It may be that your date_format and time_format settings are not the same format as what you are entering (which I think is Y-m-d, H:i)

Here's the region block (o-m-N are all PHP's ISO date settings):

  ###### REGION ######                                                                                                                                                                                                                                                      
  'region' => array(                                                                                                                                                                                                                                                        
     'time_format' => 'H:i',                                                                                                                                                                                                                                                
     'date_format' => 'o-m-N ',                                                                                                                                                                                                                                             
     'datetime_separator' => NULL,                                                                                                                                                                                                                                          
     'timezone' => 'America/Chicago',                                                                                                                                                                                                                                       
  ),                                                                                                                                                                                                                                                                        
  ######## 

The N in o-m-N is the "ISO-8601 numeric representation of the day of the week" – and that's exactly what Symphony displays. I guess the you're after o-m-t.

Oh, yes indeed that's the issue. But I switched to o-m-d, not o-m-t, as 't' apparently shows the count of days in the month.

Now I see why saving the changes to these dates caused the behavior noted above - it converted day portion of the date into the numeric representation of the day of the week from the actual day of the month. Then when I saved the changes, it updated the date but 'overwrote' the day (always 1-7). Repeating these steps results in the sequence above.

I'm trying to wrap my head around why PHP's date class behaves like this, as it seems bizarre to me to have date format options to return values that are date calculations or conversions (such as showing the ordinality of a day in a week, or the count of days in a month).

Everything looks like it's working perfectly now, thanks again for your time looking into this issue!

Heh, there's a lot of things bizarre with PHP's date handling, and the only consolidation I can give you is that they seem to fix/iron out some of the bugs/inconsistencies with each new release.

I'm glad everything is working for you now as expected :)