Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

SilverStripe tells to dates before 1970 to suck it


Go to End


5 Posts   1677 Views

Avatar
jackson_gabbard

Community Member, 13 Posts

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.

Avatar
dalesaurus

Community Member, 283 Posts

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

Avatar
jackson_gabbard

Community Member, 13 Posts

30 October 2009 at 5:21pm

Edited: 30/10/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.

Avatar
jackson_gabbard

Community Member, 13 Posts

30 October 2009 at 5:33pm

Can you explain your workaround a little more fully? Is that an onBeforeWrite intercept?

Avatar
dalesaurus

Community Member, 283 Posts

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.