Jump to:

23459 Posts in 18906 Topics by 2877 members

General Questions

SilverStripe Forums » General Questions » SilverStripe tells to dates before 1970 to suck it

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

Page: 1
Go to End
Author Topic: 997 Views
  • jackson_gabbard
    Avatar
    Community Member
    13 Posts

    SilverStripe tells to dates before 1970 to suck it Link to this post

    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.

  • dalesaurus
    Avatar
    Community Member
    283 Posts

    Re: SilverStripe tells to dates before 1970 to suck it Link to this post

    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

  • jackson_gabbard
    Avatar
    Community Member
    13 Posts

    Re: SilverStripe tells to dates before 1970 to suck it Link to this post

    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.

  • jackson_gabbard
    Avatar
    Community Member
    13 Posts

    Re: SilverStripe tells to dates before 1970 to suck it Link to this post

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

  • dalesaurus
    Avatar
    Community Member
    283 Posts

    Re: SilverStripe tells to dates before 1970 to suck it Link to this post

    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.

    997 Views
Page: 1
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.