Time Ago from a different time besides Date.now

[joshrowley]

Hi! Great library here. I'm wondering if there's any interest in adding a feature to allow you to specify a different way to calculate the current time besides using Date.now

The use case is that I want to display time ago, but I do not trust the client's clock and instead send a timestamp from my server, compare that to the client's time, and then use that to calculate a consistent offset that I use to calculate the time ago. I rolled this myself but I'd love to replace with a open source component.

I'll probably still fork this and add it for my own usage, just throwing it out there to see what the maintainers of this package would think about it and whether it'd be a good PR / open source contribution candidate. Thanks for your time and energy!! 😄

[nmn]

@joshrowley This is an interesting idea that basically no one has ever asked for.

My basic philosophy with react-timeago is that I'm happy to add new features as long as people who don't want that feature don't have to pay for it. This is why language support was added with custom formatter functions that are imported separately.

If you have an idea like that I'm all for it. But before that happens, here's a few things to consider:

1. You can technically customize the output completely using a formatter function. This function gets a raw difference in milliseconds so you could easily add your own offset to it, and then use the built in formatters to convert it to a string. However, formatter functions need to be synchronous which means a server-call is not going to be straightforward.
2. It's probably easy enough to make a Date.now() a prop on the component, with a default value. But again, this will probably need to be synchronous, so a server-call won't exactly be straightforward.

---

Any other ideas?

[allenz-crypto]

@nmn There should be an option to use a static time that we can pass in as a prop instead of Date.now() for the initial render, but it can use Date.now() on subsequent updates. The reason for this is that React-timeago is being used for server side rendering but because of the way that it uses Date.now() I will always end up with Invalid checksum with server-side rendering

I believe React-timeago should support this use case for better integration with React

[joshrowley]

Hey @nmn , I was able to use the formatter function to do this (I didn't need any async behavior because I send the server time in the response headers with my data request which happens before any components needing TimeAgo render). Worked out great 👍 , thanks! This can be closed unless you wanna keep it open for @allenylzhou's comment.

[nmn]

@allenylzhou I like this solution the best so far:

Ask for an initial render string which is static. Use componentDidMount (which only fires on the client side) to then revert to the current behaviour.

This way, the server-side render and the first render of the client-side will match up. (It'll just be a static string). But after that it will become a dynamic component again.

That said, this behaviour can be put in a container component. I'll add that container component as an optional file you can use from the package, but in the mean time you can do it your self.

class staticContainer extends React.Component {
  state = {mounted: false}
  componentDidMount () { this.setState({mounted: true}) }
  render () {
    const {children, ...props} = this.props
    if (!this.state.mounted) {
      return <span>{children}</span>
    }
    return <TimeAgo {...props} />
  }
}

@joshrowley This might be a better solution for you too.

[alexkrolick]

Another use case for this is for Jest testing - if you snapshot a component with a TimeAgo, subsequent tests will have a different Date.now and fail. One solution is to mock Date.now itself, but it may have unintended side effects.

[nmn]

This feature was added and released. You can now override a the 'now' prop.