Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow user to define custom time format #25

Closed
hurf opened this issue Aug 7, 2015 · 10 comments
Closed

Allow user to define custom time format #25

hurf opened this issue Aug 7, 2015 · 10 comments

Comments

@hurf
Copy link
Contributor

hurf commented Aug 7, 2015

I'm using go-humanize to format time. But it seems output like '12 seconds ago' is too long for me. So I'm thinking if we can allow users to customize their own output format?

@dmitshur
Copy link
Collaborator

dmitshur commented Aug 7, 2015

How would you specify it?

Unless you have a good proposal to do this, it seems like it's be shorter to simply implement what you want yourself in your project, custom for your needs. As an example, I wanted something like humanize.Time except to have it always say "less than a minute ago" for time spans of less than a minute. I just wrote it, the func was 4 lines of code.

@dmitshur
Copy link
Collaborator

dmitshur commented Aug 7, 2015

Also, have you seen humanize.RelTime? It lets you specify custom labels for times that earlier and later.

@hurf
Copy link
Contributor Author

hurf commented Aug 7, 2015

@shurcooL - Thanks! Accutally I want something like '12s ago' or '21 days'(I don't want to use week) . I've wrote the code and will submit a PR for it.

@tj
Copy link

tj commented Apr 11, 2016

I'd like this as well, seems to be a common mistake that libs like this append "ago".

EDIT: just saw the RelTime comment haha. That works. Wouldn't mind having humanize.Duration(n) with no "ago", then you can easily have Resolved in %s -> Resolved in 5 minutes etc, letting the dev append whatever is appropriate for their domain.

@dmitshur
Copy link
Collaborator

@tj, humanize.Duration(n) sounds reasonable to me at a surface glance. But please run that proposal by @dustin. It's really hard to control feature-creep in the API of this library. We still haven't even merged #26 after all this time.

@tj
Copy link

tj commented Apr 21, 2016

Hmm actually on second thought I do think it would be nice, I just got bit by it adding the opinionated "now" for tiny deltas.

@dustin
Copy link
Owner

dustin commented Apr 21, 2016

I'll send up a PR in a few minutes.

On Wed, Apr 20, 2016 at 5:21 PM TJ Holowaychuk notifications@github.com
wrote:

Hmm actually on second thought I do think it would be nice, I just got bit
by it adding the opinionated "now" for tiny deltas


You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#25 (comment)

dustin added a commit that referenced this issue Apr 21, 2016
@dustin
Copy link
Owner

dustin commented Apr 21, 2016

Sorry, took me a bit more than a couple of minutes to get off the bus, but I think this may do what you want.

In particular:

  1. Arbitrary ranges.
  2. Nanosecond precision.

The first one was I think what was being asked for in particular.

The second is required because the way it was implemented rounded everything to seconds. The general vision of RelTime was to show time for humans on a page where things are meant to be presented in human scales. time.Duration.String() seems well suited for the rest of these cases, but there are plenty of reasons to allow people to specify their own arbitrary boundaries.

@tj
Copy link

tj commented Apr 27, 2016

Understandable. I was thinking it could be something like:

func Time(t time.Time) string {
    if t.Before(time.Now()) {
        return Duration(time.Now().Sub(t)) + " ago"
    } else {
        return Duration(t.Sub(time.Now())) + " from now"
    }
}

Then if you have a different domain like mine where you'd just like to say "Resolved in X minutes" or similar it's no problem, no strings.Trim() required with RelTime.

@tj
Copy link

tj commented Apr 27, 2016

I guess for my case rounding up or down entire hours etc is not precise enough anyway haha, but hey 😄

dustin added a commit that referenced this issue Jul 21, 2016
@dustin dustin closed this as completed Jul 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants