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

Is there any scope in this repository for converting "humanized" text back to time.Time ? #73

Open
arjunmahishi opened this issue Jul 28, 2018 · 5 comments

Comments

@arjunmahishi
Copy link

No description provided.

@dustin
Copy link
Owner

dustin commented Aug 5, 2018

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.

@arjunmahishi
Copy link
Author

arjunmahishi commented Aug 6, 2018

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.

@dsoprea
Copy link

dsoprea commented Jan 9, 2019

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").

@sabhiram
Copy link

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?

@dsoprea
Copy link

dsoprea commented Jul 20, 2019

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

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