Allow dropping of fractional time parts and relax a bit parsing syntax

[lsilvest]

It would be nice to allow, amongst others:

nanotime("2019-09-10")   # like POSIXct
nanotime("2019-09-10 America/New_York") # often more natural to specify a time zone than an offset
nanotime("2019-09-10 20:00:00") # forgive the missing 'T'!

In output, the fractional time and parts could be omitted when no element of the vector to be printed has fractional part. Again this would be like POSIXct.

Finally, in output, the default prints out the time zone offset, but the timezone abbreviation is shorter and would be the same as POSIXct:

[1] 2019-09-10T20:00:00.000000001 CST

This saves one to two characters per printout.

Finally, besides the missing 'T', there could also be forgiveness for using '/' or '' instead of '-' as date separator?

[eddelbuettel]

All good. Plus flexibility on input ie recognise

"2019-09-10"
20190910
20190910L
as.factor("2019-09-10")

and so on.

[lsilvest]

We allow nanotime(1) with numeric, integer or integer64, so we won't be able to unambiguously also parse nanotime(20190910)...

To get the ball rolling for an exhaustive specification when the input is character:

1. Hour/minute/seconds, nanoseconds, offset are all optional,

2019-09-10
2019-09-10T01:00:00
2019-09-10T01:00:00.123
2019-09-10T01:00:00.123000
2019-09-10T01:00:00.123000000
2019-09-10T01:00:00-00:04
2019-09-10-00:05
etc.

2. "T", "-" optional and "-" separator can be replaced by "/"

20190910 01:00:00.123
20190910 01:00:00.123
2019/09/10T01:00:00.123

3. Nanoseconds allows "_" as 1000th separator

2019-09-10 01:00:00.123_000_001

4. The timezone offset, if not specified, is taken from the environment; the timezone name can be specified in lieu of the offset:

2019-09-10 01:00:00.123
2019-09-10 01:00:00.123-00:04
2019-09-10 01:00:00.123 America/New_York

5. If a format is specified then it is given precedence, but if the parsing fails, the usual format as described above is applied. So having a format will still allow "normal" nanotime input (but at a performance cost).

6. For output, the time and fractional parts will be omitted where possible. The precision to use will be determined over the whole visible vector output; the fractional part will be in increments of 1/1000th.

2019-09-10 EST
2019-09-10T01:00:00 EST
2019-09-19T01:00:00.000 EST
2019-09-19T01:00:00.000000 EST

Hopefully this makes the handling of nanotime as little easier and there's nothing here that should cost much in terms of performance.

[eddelbuettel]

That reads well. Some quick comments:

0. I think we need numeric, integer, integer64, ... input within limits. We clearly can cope with integer64 in (no loss). The other are tricky. In anytime I at first tried heuristics: if 8 digits beteen 18000000 and 20991231 then interpret as year --> bad idea. I now take the number as is, but anydate() dates is a (fractional int) offset to epoch 0 (for 1970-01-01), anytime does its posixt thing. So if we got, say, 12345L then that is maybe just 12345 nanosecs past epoch? Anyway.... details.

1. and 2. are good.

2. I love it

3. seems senisble too.

4. Unsure. I think we also want uncoditional long displays. To be seen. Also details.

Yay to having specs. I feel like a grown-up now.

[lsilvest]

0: absolutely, and I think we already have it working right now:

nanotime(12345L)
[1] "1970-01-01T00:00:00.000012345+00:00"

For output, unconditional long displays would occur if the user specifies a format. But alternatively, we could have another environment variable that controls this feature. Still think it should be on by default, as it really helps visually and the hope is that nanotime will be adopted even by people who don't need nanosecond precision.