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

ParseDuration API #1

Open
wojtekk-ac opened this issue Apr 17, 2020 · 13 comments
Open

ParseDuration API #1

wojtekk-ac opened this issue Apr 17, 2020 · 13 comments

Comments

@wojtekk-ac
Copy link

Hi!

I have cases where I need parsed time.Duration, without immediate arithmetics like tparse.AddDuration has.

Can parsing of the duration be exposed in the API in the same way as time.ParseDuration is?

@karrick
Copy link
Owner

karrick commented Apr 19, 2020

I absolutely think there is merit to your request. The only reason the API is structured the way it is is because not every month has 30 days.

For instance, when I add 1 month to February 3, do I get March 3? What about the difference between when it is not a leap year and when it is a leap year?

Go does not have a concept of a time duration of one month. Is one month always 30 days? Is one month 31 days, or 28, or 29? I did not want to have to answer this sort of question. So I defaulted to saying the length of one month depends on which month, and I allowed the Go standard library to add duration concretely to a given moment in time.

Maybe a work around that might work for you is using tparse.AbsoluteDuration function to return an absolute duration. However, it's based on a reference time. So calculating the same absolute duration using now and a string might be different depending on when now is.

func ExampleAbsoluteDuration() {
	t1 := time.Date(2009, time.November, 10, 23, 0, 0, 0, time.UTC)

	d1, err := AbsoluteDuration(t1, "1.5month")
	if err != nil {
		fmt.Println(err)
		return
	}

	fmt.Println(d1)

	t2 := time.Date(2020, time.February, 10, 23, 0, 0, 0, time.UTC)

	d2, err := AbsoluteDuration(t2, "1.5month")
	if err != nil {
		fmt.Println(err)
		return
	}

	fmt.Println(d2)
	// Output:
	// 1080h0m0s
	// 1056h0m0s
}

@karrick
Copy link
Owner

karrick commented Apr 19, 2020

I am open to other suggestions you might have...

@wkhere
Copy link

wkhere commented Apr 23, 2020

Ahhh.... you're right.

Now I remember I also had this conclusion some time ago when working on my own package similar to yours. Then, bah, few months, I see your package more advanced, apparently I forgot about the original problem ;)

well then. Thanks for explanations 😎

@g13013
Copy link

g13013 commented May 11, 2020

I also need this, any chance this would be implemented ?

d, err := tparse.ParseDuration("1.5month") // 45 days ?

@karrick
Copy link
Owner

karrick commented May 11, 2020

@g13013, may I ask whether you read this thread?

@g13013
Copy link

g13013 commented May 11, 2020

@karrick yes

@karrick
Copy link
Owner

karrick commented May 11, 2020

@g13013, What do you think about using AbsoluteDuration for your needs?

#1 (comment)

If AbsouluteDuration is not helpful, then what do you propose to be the length of 1.5 months long?

@g13013
Copy link

g13013 commented May 11, 2020

@karrick IMO dealing with duration should be straightforward, no reference date is involved so the month notation for a duration only should be 30d, which equivalent to 4w so my suggestion is to use AbsoluteDuration for time relative operations which may imply special meaning for month/year, and something like ParseDuration which returns duration with always 30days for months and 365days for years.

var month = time.Hour * 24 * 30
var year = time.Hour * 24 * 365

@karrick
Copy link
Owner

karrick commented May 12, 2020

January: 31
February: 28, or 29, depending on the year
March: 31
April: 30
May: 31
June: 30
July: 31
August: 31
September: 30
October: 31
November: 30
December: 31

Histogram:
28, 29: 1
30: 4
31: 7

I'm not sure 30 days is a reasonable default, as there are twice as many months with other than 30 days in it compared to the number of months with 30 days in it.

Also, one week is definitely 7 days, and 4 weeks is 28 days: 7 days/week * 4 weeks = 28 days. Suggesting that one month is 4 weeks, or that 30 days is 4 weeks is ignoring the mess that is our calendar.

I suppose we are stuck with the ickiness of the calendar that we have.

@wkhere
Copy link

wkhere commented May 14, 2020

Agree with @karrick . Month can't be 30d or 4w. That would kill sanity very soon. ;)

@wkhere
Copy link

wkhere commented May 14, 2020

@karrick Btw I as originator of this issue propose to close it as it seems to bring only confusion. Yes, if month unit, which is ambiguous, can be parsed then the only right API is AbsoluteDuration like you did.

@wkhere
Copy link

wkhere commented May 14, 2020

PS. Sorry I used the wrong login at start, @wojtekk-ac is my corporate account.

@g13013
Copy link

g13013 commented May 15, 2020

We are talking about duration here not dates.

I don't understand the difference between month and year ! if we are concerned about what a month is then the same think should be for a year

On the other hand it is common to see in software to express timeouts like, for lets say, a cookie duration

var cookieDuration = time.Hour*24*365
var sessionDuration = time.Hour*24*30

in this case I don't mind if this is a leap year or common year. the same thing for a month, leap year or not, in this particular case I don't mind about the actual month duration, all what I need is 30 days as an approximation for a month duration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants