smarter and improved #9

Closed
wants to merge 15 commits into
from

Projects

None yet

6 participants

@fent

I've added several new options to this library. All of them include tests and there is documentation in the readme for them.

$.fn.timeago.defaults = {
  // The default attribute to put the ISO8601 absolute time to parse.
  attr: 'datetime',

  // An extra space character will be added between the time and the unit.
  // '1 minute' will look like '1minute' with spacing set to `false`.
  spacing: true,

  // Will enable displaying text approximation words
  // such as 'about 1 hour' and 'almost 2 years'.
  approximate: true,

  // The text generated by Smart Time Ago will look like '3 hours ago'.
  // If you want the text looks like '3 hours from now',
  // you might need change the 'suffix' to ' from now'.
  suffix: ' ago',

  // Will show how many seconds. Instead of 'less than a minute ago' you'll see '24 seconds ago'.
  showSeconds: false,

  // You can specify how many seconds, below 59, to show a 'just now' message
  // instead of '1 second ago'.
  showNow: false,

  // After a date's relative time is too big,
  // you might want to display its absolute version.
  // For example, if after one month you don't want to display '2 years ago',
  // you can make `maxRelative` equal `2592000` which is a month in seconds.
  // Then specify an absolute displaying date function.
  maxRelative: false,
  absoluteDate: function(date, datetime) { return datetime; }
};

If you notice, I also removed the dir and selector options, because those are not needed. jQuery already has a selector engine, and it's already possible to call timeago on dynamically added elements. It makes much more sense for the user to be able to select what elements to use with time ago like this

$('.timeago').timeago();

instead of

$('body').timeago();

Also, this way, each of the elements get their own TimeAgo instance, and therefore their own timeout. I didn't really understand why the dir option was needed, it would mean that every single date for that instance would be updated even unnecessarily, which I think goes in the wrong direction if we want this to be smart.

Also, I made this much smarter. The timeouts are now set to go off exactly when the relative date will change, and not before or much much after. Being more accurate with timeouts is smarter. :)

@poshboytl
Pragmatic.ly member

Thanks for the big PR. :D Very busy these days. So didn't get a chance to review all the stuff.
Will dig into it latter.
Thanks again.

@fent

No problem. We're all busy. :)

@fent

Any update on merging this?

@andreoav

@fent This works with languages that "ago" is a prefix? See #7
There's no "prefix" option in the new plugin defaults.

@andreoav

Oh! Ok. I was looking at the wrong place.

@t3chn0r

Thanks @fent, awesome changes!

@t3chn0r

@fent, I was just working with your new version and for some reason iOS devices were failing with an error. I traced the error to the bind in TimeAgo.prototype.startTimer, it seems bind() is not supported in iOS and it gives a weird error saying "undefined is not a function". I just replaced the code with the original (a function() containing just a return self.refresh()) and everything seems to be working fine now.

@fent

Thank you good catch @t3chn0r

@hatemalimam

I used this plugin which is working perfectly, BUT you have to apply the timezone because it compare the returned date by the computer date since it's javascript.

maybe you can help me with thinking. I have two cases the first case where I calculate timeago on server (PHP) and the second case where I calculate the timeago by this javascript plugin which update the time each minute.

the first case is more solid, why because since the date on the server is always UTC and the returned date will be UTC it will always calculate right, but I will lose the nice self-updating functionality.
the second case is more fun, but I have to return the date in locale timezone of the user who is selected on his profile.
for example the user has to go to his profile and select his right timezone to make this plugin works right, and if the time on his computer is not accurate it won't calculate right (since I noticed that the comparison is based on the OS Clock) which is returned by Javascript ....
to prove this, I changed the clock of the mac 5 minutes back, and when the plugin updated the values it toke the dates 5 minutes back !!

BTW, I'm no Javascript Expert, just a normal developer who wants the best for this plugin (an option to pass the current time to compare based on it)

Thank you.

@fent

I think it expects a date formatted as ISO8601. You can print your dates in that format with PHP
http://www.php.net/manual/en/class.datetime.php#datetime.constants.types

No timezone information is required this way.

@hatemalimam

Yes that's exactly what I do, but the problem is in which timezone I have to print the date!!
The server's timezone is UTC, and mine is Europe/Rome which is one hour more than UTC, so let say that I have current time printed and passed to this plugin through time tag it will print 1 hour ago.
I hope you got what I mean.

@hatemalimam

Am I wrong in any point ?

@fent

Hmm that's strange, the timezones we use this with are UTC too, we convert them to ISO strings to pass them to timeago and they work without issues. An example timezone looks like Wed Aug 27 13:08:45 +0000 2008 and we convert that to ISO.

@t3chn0r

I just did a quick test and everything works fine... ISO8601 format is always in UTC and smarttime takes into consideration that when calculating the time passed.

What I did in my quick test:

  • Server is running in Eastern Time (UTC - 5)
  • Value in datetime is stored in ISO8601
  • One machine in same time zone as the server (remember that the date is already in UTC) show 2 minutes ago (just an example)
  • Another computer set to UTC-3 (Buenos Aires, Argentina) shows also 2 minutes ago.
@t3chn0r

Everything works fine because you are passing a UTC time and smarttime is using Date().getTime() which also returns the number of milliseconds since 1970/01/01 00:00:00 UTC...

Date.getTime() doesn't return the amount of milliseconds from 1970/01/01 00:00:00 YOUR-TIMEZONE-HERE

@hatemalimam

Hmmm, that's odd!!
I'll try again un the morning, maybe I'm missing something.
Thank you guys for your help.
I'll reply next thing in the morning.

@hatemalimam

Maybe my way of converting the timestap to iso 8601 is just wrong, I found out this post, I'll try to stick to it and see what happens, anyway I'll reply soon.
Thank you again
And oh an example on this plugin along with php use on the website would be helpfull for others too.
Keep it up. As I said I'll reply soon to confirm.
http://stackoverflow.com/questions/2471832/how-to-convert-a-unix-timestamp-to-an-iso8601-timestamp-in-php

@hatemalimam

now this is the output html

<time class="timeago" datetime="2013-02-01 12:40:05">about 1 hour ago</time>

the datetime is the current time in UTC !!!
Am I missing something here, maybe the formatting of the timestamp ??!!

@t3chn0r

I use date('c') to format the timestamp, the HTML then ends up like <time class="timeago" datetime="2013-02-01T13:55:48+01:00"></time>

The timestamp is obviously generated server side so make sure the server's time, timezone, daylight saving time, etc is set in the correct way.

@hatemalimam

yes that's what I was missing the formatting !!

<?php
public function ISO8601($utcTimestamp) {
        return date("c", strtotime($utcTimestamp));
    }
?>

This function would do the conversion correctly, inorder to display it as expected, thank you man, thanks all.
I think it's a good idea to include this function in the HOW-TO of this plugin in a PHP section code, or just mention that the passed timezone has to be converted to ISO8601.

Grazie a tutti.

@rpocklin

So... what's the status of this PR?

@fent fent Merge remote-tracking branch 'upstream/master'
Conflicts:
	lib/timeago.js
	src/timeago.coffee
2dc0341
@fent

I just merged the latest changes into this PR to keep it up to date, and encourage a faster merge into original repo process.

@fent fent closed this Feb 25, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment