Closed jbfaden closed 1 year ago
I've change it so that --range is used instead of --timeRange. This shortens the name and avoids camel case. I've added support for --range=- and --name=- .
It seems formatRange
is implied if timeRange
is given and parse
is implied if not and so --parse
and --formatRange
are redundant.
Does your code support the now
keyword that is not a part of the standard?
I followed README and it worked. But README uses camel case for formatRange and timeRange.
Maybe you need to refresh, I changed it around the same time you post. As for "now", I can put that in. It's not a standard thing, but it's very useful...
I see what happened. You have a camelCase formatRange
but changed timeRange
to be just range
. I was thinking you got rid of all camelCase.
Any thoughts on the redundancy issue?
Yes, I don't like the "formatRange" name either. Maybe I should just call it "format" and not worry about the format/parse asymmetry. (Parse always returns one thing, while formatRange returns 1 or more.)
I don't agree with you on the redundancy issue, or at least it seems harmless to me. Whether you are parsing or formatting is a huge difference, and I would want this to be explicit.
Bob suggested adding a command line API, and I've added and extended this. This can parse and format time ranges, like so:
and
Also the name and timeRange parameters should allow for -, meaning that stdin will be used to feed in a list of names or timeRanges.