ParseDuration API

[wojtekk-ac]

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]

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]

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

[wkhere]

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]

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

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

[karrick]

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

[g13013]

@karrick yes

[karrick]

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

https://github.com/karrick/tparse/issues/1#issuecomment-616174287

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

[g13013]

@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]

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]

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

[wkhere]

@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]

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

[g13013]

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.