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   1007 Views

Avatar
jackson_gabbard

30 October 2009 at 4:21pm Community Member, 13 Posts

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

30 October 2009 at 4:46pm Community Member, 283 Posts

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

30 October 2009 at 5:21pm (Last edited: 30 October 2009 5:24pm), Community Member, 13 Posts

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

30 October 2009 at 5:33pm Community Member, 13 Posts

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

Avatar
dalesaurus

31 October 2009 at 4:26am Community Member, 283 Posts

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.