Git Product home page Git Product logo

Comments (5)

dustin avatar dustin commented on June 25, 2024 3

That sounds like a huge, fuzzy task. I've done this in projects before in https://github.com/dustin/seriesly/blob/master/timelib/time.go#L110-L129 -- but that was for a relatively small number of timestamp formats that are constrained. If you want to try to guess what time someone is communicating (e.g., tomorrow at three), that could be a much larger, and less deterministic project. I can't even do that reliably with my friends, many of whom seem to think there are twelve hours in a day and they occur twice.

from go-humanize.

arjunmahishi avatar arjunmahishi commented on June 25, 2024

But it could work on a very basic level, right? like last/next month/year/day/week, x days/months.. ago/later etc
I have this much working.

from go-humanize.

dsoprea avatar dsoprea commented on June 25, 2024

It seems incomplete to be able to produce relative time phrases but to then not be able to parse them (e.g. "6 months ago").

from go-humanize.

sabhiram avatar sabhiram commented on June 25, 2024

Given that now (time.Time)is lost and was an input to figuring out the relative time (6 months ago) a time.Duration, how do you propose you figure out the intended now to offset the duration by? For example, if the string was constructed a year ago and read "6 months ago" - you actually want a time (I assume), a year and a half ago, not half a year. Right?

from go-humanize.

dsoprea avatar dsoprea commented on June 25, 2024

That's a consideration of the person using it. The same could be said for any relative distance. Obviously, such a thing would not make sense and, in most cases, is not a concern. No one stores a string saying "6 months ago" in the database for timestamps, nor does anyone store such a string in the database expecting to decode it twenty years later back to the original time. Taken from the other direction, you're supposing that it's impossible that anyone should ever have the need, which is not accurate. Just write the provision and let the people use it that need it. That's Separation of Concerns, baby.

I wrote a project to manage this six months ago. It also handles both absolute and relative quantities ("twenty minutes" vs "twenty minutes from now"): https://github.com/dsoprea/go-time-parse

https://github.com/dsoprea/go-time-parse/blob/master/parse_test.go:

{
    {"1 second ago", PhraseTypeTime, time.Second * 1 * -1},
    {"6 days ago", PhraseTypeTime, oneDay * 6 * -1},
    {"1 week ago", PhraseTypeTime, oneWeek * 1 * -1},
    {"2 weeks ago", PhraseTypeTime, oneWeek * 2 * -1},
    {"1 second from now", PhraseTypeTime, time.Second * 1},
    {"12 seconds from now", PhraseTypeTime, time.Second * 12},
    {"45 seconds from now", PhraseTypeTime, time.Second * 45},
    {"15 minutes from now", PhraseTypeTime, time.Minute * 15},
    {"2 hours from now", PhraseTypeTime, time.Hour * 2},
    {"21 hours from now", PhraseTypeTime, time.Hour * 21},
    {"1 day from now", PhraseTypeTime, oneDay * 1},
    {"2 days from now", PhraseTypeTime, oneDay * 2},
    {"3 days from now", PhraseTypeTime, oneDay * 3},
    {"2 weeks from now", PhraseTypeTime, oneWeek * 2},
    {"1 month from now", PhraseTypeTime, oneMonth * 1},
    {"1 year from now", PhraseTypeTime, oneYear * 1},
    {"2 years from now", PhraseTypeTime, oneYear * 2},
    {"30 seconds from now", PhraseTypeTime, time.Second * 30},
    {"120 minutes from now", PhraseTypeTime, time.Minute * 120},
    {"1260 minutes from now", PhraseTypeTime, time.Minute * 1260},
    {"1 week from now", PhraseTypeTime, oneWeek},
    {"4 weeks from now", PhraseTypeTime, oneWeek * 4},
    {"25 weeks from now", PhraseTypeTime, oneWeek * 25},
    {"12 months from now", PhraseTypeTime, oneMonth * 12},
    {"24 months from now", PhraseTypeTime, oneMonth * 24},
    {"now", PhraseTypeTime, 0},
    {"every 15 minutes", PhraseTypeInterval, time.Minute * 15},
}

It doesn't have to be complicated. The standard use-case doesn't have to involve fuzziness at all. Once again, it really depends on what people are expecting to use it for, and they're gonna only use it for a use-case that makes sense, e.g. simple configurations and command-line arguments. If this project doesn't provide something that falls within the standard range of something that some developers need, they're just gonna have to write it themselves, where you'd be doing them a favor by preventing them from having to do so.

Dustin

from go-humanize.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.