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.

[aaronsp777]

Rob I agree with your canned answer but you answered the wrong question.
The question is should flags.Duration (not the time package) accept days?
On Jun 29, 2015 8:15 PM, "Rob Pike" [email protected] wrote:

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

—
Reply to this email directly or view it on GitHub
#11473 (comment).

[robpike]

There's an argument that they should agree in what they accept, plus the original answer applies here too: How long is a day?

[dr2chase]

Today (2015-06-30, day with a leap second), the length of a day is 23 times the length of a standard hour, plus the length of the last UTC hour. That's how long a day is, in terms of questions that we are already willing to answer, combined using operations that we understand.

It's also safe to say that someone is more likely to notice a leap second when they happen to ask for a minute spanning the leap second boundary than when they ask for a day spanning the leap second boundary, yet somehow this ambiguity does not prevent us from supporting minutes as a Duration.

Furthermore, quite a few places (Google and Amazon among them, as well as quite a few financial exchanges, according to the article cited above) are smearing the leap second anyway, so actually all our larger-than-second durations at Google (or at Amazon, etc) are slightly wrong today anyhow.

Do we have a better reason than this alleged ambiguity for saying "no"? Pushing the eat-your-antiambiguity-spinach all the way out to the command line seems user-unfriendly.

[robpike]

Some days are only 23 hours long, some are 25. Most are 24, but not today. I think it's fine to stop at hours, which are often 1/24 of a day. Otherwise where do you stop? Week? Month? Year? Decade? Century? Millennium? Era? We must stop somewhere, and for computer usage hour seems like a fine drawing point since real ambiguity sets in at the next level. (The one second of a minute around a leap second is not a real issue here.)