back to listing index

flag: let Duration accept days · Issue #11473 · golang/go

[web search]
Original source (github.com)
Tags: golang
Clipped on: 2016-02-12

Skip to content

flag: let Duration accept days #11473

Closed
aaronsp777 opened this Issue on Jun 29, 2015 · 15 comments

Labels

None yet

Milestone

No milestone

Assignee

No one assigned

Notifications

You’re not receiving notifications from this thread.

5 participants

Image (Asset 2/13) alt= aaronsp777 Image (Asset 3/13) alt= bradfitz Image (Asset 4/13) alt= dr2chase Image (Asset 5/13) alt= josharian Image (Asset 6/13) alt= robpike
Image (Asset 7/13) alt=

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.

Image (Asset 8/13) alt=
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
Image (Asset 9/13) alt=

and make ParseDuration accept the suffix "d" ?

Image (Asset 11/13) alt=

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

Image (Asset 12/13) alt=
Go member

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

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.

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

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

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 changed the title from time.Duration for days to flag: let Duration accept days on Jun 29, 2015
Go member

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

josharian reopened this on Jun 29, 2015

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

robpike closed this on Jun 29, 2015
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?

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

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.

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.)

Attach files by dragging & dropping, selecting them, or pasting from the clipboard.