21490 Posts in 5783 Topics by 2622 members
|
Page:
1
|
Go to End | |
| Author | Topic: | 845 Views |
-
SilverStripe tells to dates before 1970 to suck it
30 October 2009 at 4:21pm
Hey everyone,
I'm finding something strange with a site I'm building in SS. I have a Date field in the $db static on a DataObject. To the user, it appears as a CalendarDateField managed via the ModelAdmin. With the nature of the DataObject (the dates relate to people's birth dates and death dates), there will be lots of dates before 1970. When I enter a date before 1970 and save the DataObject, it gets set to 1/1/1970. No bueno.
Interestingly, when I edit the field manually in the database via phpMyAdmin, I can set the date to any of the acceptable MySQL date range values (i.e. 1000-01-01 at the earliest). Also of interest is that when I reload the DataObject in the admin after editing the DB directly, the field will show up with the pre-1970 date I enter. Upon saving, it reverts back to 1970 whether I edit it or not. So, this means the switcheroo is happening in the save routine, but I haven't found it yet.
I've been digging for a few minutes and thought I ought to post here about it to see if anyone else had encountered this as a issue. If I figure it out, I'll post back with the solution.
-
Re: SilverStripe tells to dates before 1970 to suck it
30 October 2009 at 4:46pm
You are being i18OWNED by the SSDatetime field, I've hit this many times. 2.3 was very careful to allow for NZ dates by default, just take a look at the setValue code:
function setValue($value) {
// Default to NZ date format - strtotime expects a US date
if(ereg('^([0-9]+)/([0-9]+)/([0-9]+)$', $value, $parts))
$value = "$parts[2]/$parts[1]/$parts[3]";if($value) $this->value = date('Y-m-d H:i:s', strtotime($value));
else $value = null;
}This is a baffling piece of code considering the effort that went in to internationalization. Most of the JS datepickers and such all post the data in some x/y/z format that the ereg hoses.
I've had to make a point to always send my dates as MySQL formatted dates to avoid that ereg:
$thing->somedate = date('Y-m-d H:i:s');
This also corresponds with some gratuitous use of strtotime. Also this thread has tons of help in it:
http://www.silverstripe.org/archive/show/220545?start=0#post221987 -
Re: SilverStripe tells to dates before 1970 to suck it
30 October 2009 at 5:21pm Last edited: 30 October 2009 5:24pm
Naturally, Dale beat me to it. For those who want the gritty details, here's the post I was about to make. Daleosaurus, you're one fabulous Trannysaurus Rex.
-----
Okay, so I think I've found the problem-- line 19 of sapphire/core/model/fieldtypes/Date.php
if($value && is_string($value)) $this->value = date('Y-m-d', strtotime($value));
else $value = null;This line gets executed when the value of a Date DBField is specified. Since PHP is not good at parsing date strings for dates prior to the UNIX epoch, you get mixed results.
For me, I can save a date in the year 1913 or 1930, etc. but not something much older. 1900 for instance fails reliable, getting assigned to 1970.
-
Re: SilverStripe tells to dates before 1970 to suck it
30 October 2009 at 5:33pm
Can you explain your workaround a little more fully? Is that an onBeforeWrite intercept?
-
Re: SilverStripe tells to dates before 1970 to suck it
31 October 2009 at 4:26am
My workarounds were generally forcing whatever was inputting dates to use date('Y-m-d') before passing it back for saving. On forms it was pre-parsing the return and transforming it. For the Datepicker it was hacking the JS, per the above post I referenced.
onBeforeWrite() is also an option. None are an elegant solution. Unfortunately its all hacks right now. I think I've seen several open bugs that are prioritized for 2.4, but no code has been checked in or patches provided yet.
| 845 Views | ||
|
Page:
1
|
Go to Top |
