Improving intial date settings logic

Thanks for your work on that. I'd appreciate if you could make a patch. This would be a lot easier to handle. Check out ttp://drupal.org/patch for information on how to create patches. Please use the DRUPAL-6--2 cvs branch.

Thanks!

Thank you for the patch. I applied it to the 6.x-2.0-dev version. The whole logic would need some more love. I'd like to track these improvements within this post. There was a related ticket to that (#566734: Initial time placement when first loaded syntax error).

Everybody who wants is invited to write a patch and help with that.

Information on how this initial date logic is not good enough: #607338: Initial Date Focus not Working

And another one who found this bug: #610006: Band - Interval Settings Not Working for Initial Date Focus

The issue here is that the code is converting iso8601 and gregorian dates to timestamp. Timestamp is the number of seconds since midnight Jan 1st 1970 and is why some are getting the Initial focus to be 1970. I've not looked at the SIMILE code but I suspect that if they get an error or null value as the initial focus then they are defaulting to 1900.

Suffice to say that all the date manipulations have to be done in either iso8601 or gregorian. I'll see if I can cobble up a fix but it may take me a while to a) get the time (probably not this weekend), and b) I don't really have a PHP development system.

posting some input from walwyn (thanks!). Just to avoiding to loose it.

I've had a quick whack at this and fixed the start, last, and median settings. TODO are the middle and custom but I'm off to get some sleep basically I think one will have to use the PHP DATE class to fix those. Anyway here is the updated function do with what you will.

  /**
   * Get the actual field value based on the timeline views settings and the result set of events.
   *
   * @param
   *   $option - name of the selected option
   *   result - the result set of events
   *
   * @return
   *   formated date
   *
   * Note: -fd
   * First and last fields have to be improved:
   * If the view is not sorted on the start date this would lead wrong dates.
   * Last should also check if the event has an "end" date
   */
  function getDefinedDateField($option, $options_field = '') {
    // Make sure that if there is no result that a valid date (today) is getting served.
    if ($option != 'today' && $option != 'custom' && count($this->data['events']['events']) == 0) {
      $option = 'today';
    }
    foreach ($this->data['events']['events'] as $date) {
      $t[] = timeline_date_conversion($date['start'], 'iso8601', 'iso8601');
    }
    sort($t);
    switch ($option) {
      case 'today':
        return timeline_date_conversion(time(), 'timestamp', 'gregorian');
      case 'first':
        return $t[0];
      case 'last':
        return $t[count($t)-1];
      case 'middle':
        $end = timeline_date_conversion($this->data['events']['events'][count($this->data['events']['events']) - 1]['start'], 'iso8601', 'timestamp');
        $start = timeline_date_conversion($this->data['events']['events'][0]['start'], 'iso8601', 'timestamp');
        $middle = ($start + $end) / 2;
        return timeline_date_conversion($middle, 'timestamp', 'gregorian');
      case 'median':
        return $t[round(count($t)/2)];
      case 'custom':
        if ($options_field != '') {
          return timeline_date_conversion(strtotime($options_field), 'timestamp', 'gregorian');
        }
    }
    return FALSE;
  }