Symphony.

Also with clean S23 install and the default demo workspace, I am unable to utilize and use the Date field type in sections, as it returns an error when saving entry:

Symphony Fatal Database Error: Incorrect datetime value: '2012-08-24T08:27:00+00:00' for column 'date' at row 1

An error occurred while attempting to execute the following query

INSERT INTO `sym_entries_data_23` (`entry_id`, `value`, `date`) VALUES ('7', '2012-08-24T10:27:00+02:00', '2012-08-24T08:27:00+00:00')

Any ideas what I have misconfigured? I haven't seen this issue in posts, so maybe its something with my DB?

My REGION configuration in config.php is

###### REGION ######
'region' => array(
'time_format' => 'H:i',
'date_format' => 'm/d/Y',
'datetime_separator' => ' ',
'timezone' => 'Europe/Bratislava',
),
########

Server is PHP 5.3.8, MySQL 5.1, DB utf8 - utf8unicodeci

I am not able to get to it. Thanks for any tips.

EDIT: Added screen.

Attachments:

ScreenShot670.png

Yes, also to mention, I do not edit the Date field by myself. It is prepopulated by the system itself, which is fine, but then it hangs on the given error.

The only way now I can have a Date field in a section is to use Date and Time extension, which is cool, but it does not autopopulate by frontend entry submition as the Date field did. But this is other topic.

EDIT: I would need the Date field if possible.

Thanks

Hi Juro, Did you ever find out the cause of this? I have just downloaded and installed my first ever Symphony CMS and i cannot edit anything in the default blog due to this.

Help please.

Okay so 2012-09-04 15:55:00 works, but the CMS is trying to insert 2012-09-09T15:55:00+00:00 which is what is breaking. My specs meet all the requirements for the CMS. Install script ran fine. Why would Symphony be trying to insert a different format.

Im guessing its hopefully a simple thing I am missing here. But just a little bummed it isn't working out of the box. And a little nervous to start rummaging through the code base.

Any other Sunday coders on line who can help me?

I'm wondering why the timezone offset is stored if mysql datetime doesn't support it. The manual states that dates are stored in the following format YYYY-MM-DD HH:MM:SS which should explain why 2012-09-04 15:55:00 works but 2012-09-09T15:55:00+00:00 doesn't.
After some googling, it seems this kind of error rises only when mysql is in STRICT mode (which is not the default), because otherwise the +00:00 part is ripped off silently and values are stored correctly (even if an error is present).

My guess is that we should change line #411 to use the correct format, as noted in this comment on php.net.

I'm not completely sure about what I've just written, maybe the problem lies elsewhere...

Fixed here, thanks!

Works flawlessly, thank you!

EDIT (30. oct): I went through this thread again and realized I didn't reacted back there. I thought I did. I do apologize. I have quite bussy times. Thanks for your following confirmations on this issue, further investigation and the fix. I am a frontend developer, so this issue was too big for me.

Thank you, @brendo!

Just upgraded to 2.3.1 (from 2.3) and get this error when trying to save an entry or create a new one, regardless of a date field being used:

Symphony Fatal Database Error: Incorrect datetime value: '2012-10-30T17:41:46+01:00' for column 'creation_date' at row 1

An error occurred while attempting to execute the following query

INSERT INTO `sym_entries` (`author_id`, `section_id`, `creation_date`, `modification_date`, `modification_date_gmt`, `creation_date_gmt`) VALUES ('1', '13', '2012-10-30T17:41:46+01:00', '2012-10-30T17:41:46+01:00', '2012-10-30T16:41:46+00:00', '2012-10-30T16:41:46+00:00')

The date being entered into creation_date needs to have the T time separator removed. I can hazzard a guess this will be the same for all tables that have DATETIME columns. I'll log this on the issue and reopen it.

Submitted another pull request for this and expect it to be a patch for the 2.3.1 release as it breaks all entry creation.

Thank you a ton, @designermonkey!

I'm sorry reopen this thread, but I'm just a little messed up with the releases... I get @brendo fix and @designermonkey pulls 1520 e 1532. The first one is in the 2.3.1 tag, but I haven't found the pulls (that fixed the problem for me, BTW) anywhere. So, shouldn't have a 2.3.2 tag or a fix to 2.3.1?

2.3.2 is still in beta, expecting a release candidate this weekend.