When using modules such as scheduler which deal with future dates, I found that the 'time ago' date handler format simply returned 0 when used with a future date. Instead of changing this behaviour (which may not be helpful to share with other users) I created another format called 'time span' which displays the same as 'time ago' if the date is in the past, but displays the correct date interval plus 'hence' for dates in the future.

To replicate the recent change which created 'time ago' and 'raw time ago' I have also created 'raw time span' which returns the plain time interval for past dates (just like 'raw time ago') but for future dates it returns the correct time interval preceded by a '-' and with no text appended.

The code changed is in views/handlers/views_handler_field_date.inc

I found that the final section of code could be simplified if the case where $value being empty was dealt with first. So the original code:

    switch ($format) {
      case 'raw time ago':
        return $value ? format_interval(time() - $value, is_numeric($custom_format) ? $custom_format : 2) : theme('views_nodate');
      case 'time ago':
        return $value ? t('%time ago', array('%time' => format_interval(time() - $value, is_numeric($custom_format) ? $custom_format : 2))) : theme('views_nodate');
      case 'custom':
        return $value ? format_date($value, $format, $custom_format) : theme('views_nodate');
      default:
        return $value ? format_date($value, $format) : theme('views_nodate');
    }

now becomes:

    if (!$value) {
    	return theme('views_nodate');
    }
    else {
      $time_diff = time() - $value; // will be positive for a datetime in the past (ago), and negative for a datetime in the future (hence)
      switch ($format) {
        case 'raw time ago':
          return format_interval($time_diff, is_numeric($custom_format) ? $custom_format : 2);
        case 'time ago':
          return t('%time ago', array('%time' => format_interval($time_diff, is_numeric($custom_format) ? $custom_format : 2)));
        case 'raw time span':
          return ($time_diff < 0 ? '-' : '') . format_interval(abs($time_diff), is_numeric($custom_format) ? $custom_format : 2);
        case 'time span':
          return t(($time_diff < 0 ? '%time hence' : '%time ago'), array('%time' => format_interval(abs($time_diff), is_numeric($custom_format) ? $custom_format : 2)));
        case 'custom':
          return format_date($value, $format, $custom_format);
        default:
          return format_date($value, $format);
      }
    }

I have attached a patch created against 6.x-2.5. I would be interested to hear what other users think of this modification. Certainly my users who want to see how far ahead their content is scheduled have found it very useful. If you like it, could it be considered for inclusion in the next release?

Thanks,
Jonathan

CommentFileSizeAuthor
#6 ago_hence_formatter.jpg122.4 KBjonathan1055
#2 _views_handler.time_span2.patch.txt3.31 KBjonathan1055
_views_handler.time_span.patch.txt3.35 KBjonathan1055

Comments

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Needs review

this is quite a nice extension

but i would like to use

in_array

instead of
+ if ($format == 'custom' || $format == 'raw time ago' || $format == 'time ago' || $format == 'raw time span' || $format == 'time span') {
because you can read it much better.

additional i wonder why raw time ago/span does not return the unix time code interval, shouldn't there be a think also?

setting to review

jonathan1055’s picture

jonathan1055 commented
StatusFileSize
new _views_handler.time_span2.patch.txt3.31 KB

Hi Daniel,
Thanks for the comment. Yes I can change the long if to in_array(). The reason I didn't do it in the first place is that I wanted my changes to be very clear to see. But you are right that now there are 4 values to check, it reads better in an array.

I don't quite understand your comment

additional i wonder why raw time ago/span does not return the unix time code interval, shouldn't there be a think also?

The 'raw time ago' format was added so that it just gives the result of the drupal format_interval() function with no text added. My change should not and will not alter this.

Attached is the modified patch for the array checking.

Jonathan

merlinofchaos’s picture

merlinofchaos commented
Status: Needs review » Fixed

I agree, I like this. Committed to 2.x and 3.x branches!

jonathan1055’s picture

jonathan1055 commented

Thanks very much, pleased you like it.
Jonathan

rbl’s picture

rbl commented

This was exactly what I was looking for (thanks Jonathan =)) but it's not working for me.
It displays events using my default medium date format: 15 June, 2009 - 06:16

Any idea what might be wrong?

Ricardo

jonathan1055’s picture

jonathan1055 commented
StatusFileSize
new ago_hence_formatter.jpg122.4 KB

Hi Ricardo,

When you click on your date field in the 'Fields' box in views, you should see an entry form below, and at the bottom of this is a menu selection drop-down labelled 'Date format:' - There should be two new options in this drop-down list. I have attached a screen grab to show you what you are looking for. Do you get the new options?

Jonathan

rbl’s picture

rbl commented

Hi!
I do, (should have included this in the first post) both will display the medium date format. I've cleared both caches and still no luck.

Ricardo

jonathan1055’s picture

jonathan1055 commented

OK here are some more questions. I don't know your background, so please excuse me if some of these sound trivial.
(a) Do the other date formatters work for this particular field?
(b) Does the 'ago / hence' formatter work for other date fields?
(c) Is the datefield from a content type defined by you, or is it from a built-in drupal value?
(d) Does the wrong value show in the view preview? or does it also show when you have saved the view and are using it in your site
(e) Did you apply the patch file to your existing views code, or have you downloaded the latest dev version?

That's enough for now. Has anyone else tried using the new options? either successfully or not, let me know.

Jonathan

rbl’s picture

rbl commented

No worries =)

a) They do. "Time ago" displays medium date too. Not sure if it should display "0 sec ago" like "Time ago (with ago appended)".

b) Good question. I've tried a few other dates fields and while it handled past dates well, it still displays the same behavior for future dates.

c) I'm using the event module in the content type created by it. I've just tested it with the event module on a new content type with same results. Could it be the event module? I'm using Event 6.x-2.x-dev (2009-May-29)
Do you want me to try with a custom CCK date field?

d) The wrong value is displayed in both views, the preview and the block on the public area of the site.

e) Both actually. Tried the patch first, didn't work and then updated Views to Views 6.x-2.x-dev (2009-Jun-05).

It would be great if other people could test this. Hope the problem is not on my end and I'm leading you on a wild goose chase... Anyway, thanks for your help! =)

Ricardo

rbl’s picture

rbl commented

Following my last reply I decided to try the Scheduler module and see if on the same conditions as you, it would work or not, and guess what? It works!

So, your code understands the date coming from Schedule but not from the Event module. Can it be simply a format issue?

Ricardo

jonathan1055’s picture

jonathan1055 commented

In #9 your answers to (a) and (b) need a little more explanation:
(a) I asked "Do the other date formatters work for this particular field?" You say 'they do' but then you say 'time ago displays medium date'
so this implies that other date formatters do not work.
(b) I asked "Does the 'ago / hence' formatter work for other date fields?" You say "while it handled past dates well, it still displays the same behavior for future dates". So do you mean that when the new ago/hence formatter is applied and the date is in the past you get 'x whatever ago' but when the date value is changed into a future date you get the medium date format displayed? This is odd behaviour because it suggests that the handler code selects a different formatter depending on the value, but I don't see any way that it can do this.

I have not got the event module so I can't look at that aspect, but your comment in #10 about it working fine for Scheduler is usefull as it shows that the new patch does work for you in principle. I have tested the new formatter on Drupal core dates (node created date, node updated) and these also work fine. CCK has its own completely separate date handlers and formatters so dates in user content types do not use the views date handler which is updated in this patch.

I'd like to suggest that you raise a new issue in the Event module, referencing this one, because it appears that this patch is working OK in principle. Put a forward reference here to your new issue and I'll be happy to follow up on it if there is anything I can do.

Jonathan

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.