Dates are poorly handled

Created on 4 December 2012, over 11 years ago
Updated 21 March 2023, over 1 year ago

Hello,

I jumped off my chair when I saw this piece of code:

/**
 * Defines possible duration multiplier.
 */
function rules_ui_element_duration_multipliers() {
  return array(
    1 => t('seconds'),
    60 => t('minutes'),
    3600 => t('hours'),
    // Just use approximate numbers for days (might last 23h on DST change),
    // months and years.
    86400 => t('days'),
    86400 * 30 => t('months'),
    86400 * 30 * 12 => t('years'),
  );
} 

As a consequence of those "approximate numbers", creating a simple action that adds one year to current date will be 5 days off! (Today 2012-12-04, my result is 2013-11-29).
That doesn't sound quite acceptable, does it?
Telling me "Instead of adding 1 year, you should add 31,536,000 seconds" (3600*24*365) is not a solution, as, as the comment above states it, yes, some days may be only 23h, some years may be 366 days, etc.

Second point:

public static function applyOffset($timestamp, $offset) {
  if (abs($offset) >= 86400) {

    // Get the days out of the seconds.
    $days = intval($offset / 86400);
    $sec = $offset % 86400;
    // Get the months out of the number of days.
    $months = intval($days / 30);
    $days = $days % 30;

    // Apply the offset using the DateTime::modify and convert it back to a
    // timestamp.
    $date = date_create("@$timestamp");
    $date->modify("$months months $days days $sec seconds");
  return $date->format('U');
  }
  else {
    return $timestamp + $offset;
  }
} 

This function does the opposite effect, and, when called with now(), and an offset of a year (converted in seconds, yes), is 5 days off, but in the other way (result is 2013-12-09). Some modules rely on this function (for example, Role expire β†’ ) and get erratic results.

I would suggest using real date structures instead of converting to seconds and make assumptions. That includes:

Thank you for reading me, I hope we'll get Rules even better than it is now!

David

πŸ› Bug report
Status

Active

Version

2.0

Component

Rules Core

Created by

πŸ‡―πŸ‡΅Japan David Stosik

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡­πŸ‡ΊHungary atomi

    I'm shocked that this bug has been in the Rules module since 2012!

    Date offset is incorrect πŸ› Date offset is incorrect Closed: duplicate

  • πŸ‡ΊπŸ‡ΈUnited States TR Cascadia

    *I'm* shocked that it's so important to you but you're unwilling to help. Drupal 7 is almost obsolete, so there's little incentive for anyone but you to work on it - you're the one that needs it.

  • πŸ‡¦πŸ‡ΊAustralia PetarB

    @TR I love your work and have so much respect for you but let's not pretend that Drupal 7 is going anywhere soon.
    Just look at this:
    https://www.drupal.org/project/usage/drupal β†’

    As to the OP and other people looking at this thread, its an issue I've come up against a lot. We've always converted dates to U (epoch time), done our date math, (ie, add durations etc), convert up and back to native datetime, contrary to the OP saying this isn't a solution. Actually, it's the only real guaranteed solution. You have to take responsiblity here because date are HARD... they don't follow periodicity or predictability. Don't rely on Rules for date math, there's so many issues that can come up, including plenty of issues that are completely outside the scope of Rules.

Production build 0.69.0 2024