flag: let Duration accept days

[aaronsp777]

I've got users who want to use a command line flag of "30d" meaning 30 days in the future (or past).

time.Duration is perfect, it supports Nanoseconds, Microseconds, Milliseconds, Seconds, Minutes, Hours
except it doesn't support the longer durations such as Days.

Any discussion about leap seconds, or leap years is orthogonal because it could happen across any Hour boundary as well.

[aaronsp777]

const (
        Nanosecond  Duration = 1
        Microsecond          = 1000 * Nanosecond
        Millisecond          = 1000 * Microsecond
        Second               = 1000 * Millisecond
        Minute               = 60 * Second
        Hour                 = 60 * Minute
)

Can we add a line like this:

        Day                 = 24 * Hour

[aaronsp777]

and make ParseDuration accept the suffix "d" ?

[bradfitz]

What would Day mean tomorrow?

http://www.bloomberg.com/news/articles/2015-06-28/with-61-seconds-in-a-minute-markets-brace-for-trouble

[dr2chase]

@bradfitz What does Hour mean tomorrow at 23:00:00 UTC?

[bradfitz]

Hey, I'm just repeating the argument I've heard in the past.

Once you start talking about units like Days, people are generally trying to do calendar math instead of duration math, and days could be misleading.

Not providing Day forces people to write 24 * Hour and maybe see their mistake early.

This is why we have http://golang.org/pkg/time/#Time.AddDate

[aaronsp777]

So the decision is to not allow folks to query days in the future? (Where a day is 86400 always). Yes, we have timezones and Daylight Savings times, and yes we have leep years, and yes we have leap seconds.

And yes, I brought this up knowing full well that in "36h" from now we would have a leep second
http://www.timeanddate.com/time/leap-seconds-future.html

But remember I said above "Any discussion about leap seconds, or leap years is orthogonal because it could happen across any Hour boundary as well.".

Seriously can we have a flag to specify days in the future.
(Like please show me graphs from the last 90 days). We really don't care about hours or seconds at that point, we want to show the last 90 days of graphs.

Having to specify "2160h" to mean 90d is just stupid.

[josharian]

Setting aside arguments about whether adding time.Day is a good idea, 90 * 24 * time.hour is pretty clear (unlike 2160 * time.Hour).

[aaronsp777]

It's not pretty clear when its a command line flag: (See flag.Duration)

$ my_grapher_written_in_go --start_time 30d --end_time 30d

is much easier to read than:

$ my_grapher_written_in_go --start_time``expr '24 * 60 * 1000 * 1000'``--end_time --start_time``expr '24 * 60 * 1000 * 1000'

[josharian]

Ahhhhh. Asking for flag.Duration support for 30d is distinct from asking for the addition of time.Day. I guess the lede got buried. I think that the readability argument is more compelling there.

However, flag.Duration support strongly suggests time.ParseDuration support, which in turn suggests "time.Duration".String support, which looks superficially like a slippery slope to time.Day. Although there are already strings that time.ParseDuration can parse that "time.Duration".String does not generate, like "5us" and "5m3m".

@bradfitz do you know whether flag.Duration support for days also been previously discussed and dismissed?

[bradfitz]

Don't know. I'll defer to @robpike

[robpike]

How long is a day? The answer: it depends. That's why the time package doesn't talk about these longer intervals.