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.

General Questions /

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

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

SilverStripe tells to dates before 1970 to suck it


Reply


5 Posts   1052 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.