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

[arjunmahishi]

No description provided.

[dustin]

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]

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]

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]

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]

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