Thanks!

The line 34 is to overcome the timezone setting in user’s browser. Since the calculation is done in each user browser, the js script must know how much the time different is.

If you remove the (dt.getTimezoneOffset() * 60000) addition, all user browser is assumed at GMT.

The addition is proposed by Dean in the comment at john blog. So the date that must changed is the one in the html. It must in GMT.

Check my previous comment to find the way to convert local server date into GMT, then show it as ISO format using PHP.

@unwiredbrain
You must change the date to shown in title attribute into GMT. So it must written as:
Some event that just happened

See that it is 7:45 in GMT, because your timezone is +01:00.

The javascript will use the browser timezone setting, so the result will be correct.

If you are using PHP in the server-side, this is the code to change timestamp into GMT (using server’s timezone setting), then format it to become ISO.

http://pastie.org/450720

The T and Z removal make more sense in that context.

It ends up removing all the letter Ts. so some dates fail.

e.g. “Thu Feb 5 08:02:38 PST 2009″ is parsed as
“hu Feb 5 08:02:38 PST 2009″ and subsequently fails.

It should be noted that including a timezone offset into your markup date is not a supported use case for this script. Outputting UTC time only (no hardcoded offsets in the dates) allows for the JavaScript code to interpret the date to the offset of the client.

I believe that adding support for hardcoded timezone offsets would add unnecessary complexity to the code. Output Z +/- 0 and it will work fine.

That being said, if you disagree, feel free to modify the script and re-release it! It’s all open source.


seconds = ((dt - new Date(time)) / 1000),


eg. ‘11 hours’ no ago..

not receiving a reply for months I deleted all the relative documents; my documents deleted, phpfi.com down… Guess what? I had to recreate the glitch from scratch.

Let’s assume my current system date is 2008-01-08;
Let’s assume my current system time is 08:45:00;
Let’s assume my current time zone offset is +0100;
Let’s assume my current span looks like this:
<span class="dtstart" title="2009-01-08T08:45:00Z+0100">Some event that just happened</span>

On my test page, launching $(".dtstart").humane_dates() I will see “60 Minutes”. Which is future.
That’s exactly my current local time added with my current local time zone offset.

Apart from the glitch; being a future event, isn’t it supposed to be left as it was — i.e. not humanized at all?

Can you repost somewhere else, or include the code?

I developed this for alarmd, so you can see it in action there. If you add an alarm, it will create a pretty date in the bottom right corner.

For instance, I just added an alarm for +1h, resulting in 2009-01-08T02:56:38Z. I’m in CST (-6), which is is right (it’s now 7:56PM).

Thanks,
Zach

But…

I (think I) found a glitch — from now on consider all the dates & everything treated as UTC: if you set a date to exactly now (where “now” is the instant where the page loads) the script returns a “2 Hours” — I mean: future!

Is to be said that I live in a country where right now the time zone is CEST that is GMT plus two hours (see Wikipedia for more), but, as you can easily imagine, in other countries this could vary: zero, one or two, like me, or even more.

Now: all your script runs using UTC (which is good), but at line 34 you add the current local time zone offset, which is wrong in my opinion.

I think that this should be fixed, but I look forward to your opinion.

Anyway, I still think that you should never touch a future date, and I still think that by removing the token you’ll get a more compact, readable and elegant code.

PS: just FYI, here’s my test case: http://phpfi.com/327787

Leaving the script vanilla, I get the glitch; removing the time zone offset I get the correct behavior.

Also, you can test this by adding some minutes: just modify the ‘difference’ variable in the HTML document.

I hope the whole thing is clearer now.

Have a nice day.

But there’s something I really don’t get: if I’m using a future date (think about a dtstart / dtend duet, like hCalendar does), the script treats them as past events!

If current year is 2008 and I’m planning some event for year 2009, the script says “1 Year Ago”! This is undoubtedly wrong! And should be avoided, of course.

For me, the problem resides in the first if clause: seconds should not be modified; if seconds are less than zero, then the script should do nothing, returning null.

A null returning would be very comfortable, allowing control statements as John Resig did in his original scripts; in particular, would be comfortable because you would not soil the innerHTML.

Also, if you avoid the token, all the script will instantly get more suitable for l10n, making the code more clean and readable.

Very nice! This is exactly what I was looking for.
Thanks for sharing!