Breaking: Consider removing some exports

[anowacki]

There are many things exported from NanoDates.jl that seem somewhat curious. For example, I don't understand why a user would need to have CapitalT ('T') exported. Likewise for many others. (SingleSpace, etc.) However, of course there may be very good reasons why you do export these, and please feel free to ignore my question/suggestion here.

Just from the point of view of a user, below I have listed those exports which I think could reasonably be removed in a future breaking change (e.g., v0.2):

Characters

• CapitalT
• SingleSpace
• SmallCapitalT
• SmallWhiteCircle
• SmallWhiteStar
• Underscore

Others

I'm not sure from the documentation if this is meant to be used as part of the API, or is really internal:

• reset_timekeeping

[JeffreySarnoff]

Yes .. and not breaking, more like lawn keeping. While converging on a smaller notion of the most substantive aspects of higher resolution timekeeping to promulgate advantageously for others, I made hands full of code to clarify what most simplified, what may be more generalized, how one might show and see the information with less effort and what could become very fast running. JuliaCon arrives just as the code is become more nicely dressed, and in advance of some real dusting, and letting some go as charitable donations.

Some of the reason for this package is to see how it may be when well revisited as others become familiar with specifics. So, yes.

[JeffreySarnoff]

This is a "known very near term to do" and there are places with lines of code that were essential until better ways with their own, more coherent functions and compact operative approaches got got.
So, yes. I have benefited from the attention you have shared.

[JeffreySarnoff]

reset_timekeeping serves two overlapping purposes .. it turns out that there is a way of looking at them wherein one subsumes (really, protects and provides for) the other. While client access to this is no longer necessary .. particularly as it may be accessed through import Package: packaged_onthe_inside, there are important buildables that may lean on NanoDates for which that activity simplifies the overall effort. I have let it remain published so more potential may roll downhill into valleys of the well provisioned. I may replace its current access with a better writeup of why other constructs may care for it.

[anowacki]

Okay, sorry for the noise. I'll hold off on comments and suggestions for now, since it seems you have plans for how things will develop.

[JeffreySarnoff]

just noticed this -- you have lived with the package for a while .. any changes you suggest That are surface level?

[anowacki]

(Happy to post any of these as issues or open a new one if you like.)

I haven't used NanoDates extensively, but have long wanted a nanosecond-resolved time package for use with Seis.jl (unregistered). (I rolled my own nanosecond type for LibMseed.jl but that part of it isn't meant for public consumption.) The main things keeping me from adopting it in Seis.jl would be:

1. Lack of docstrings and formal documentation. The web docs are great, but something in a similar format to what other packages provide might make it easier to navigate since people are used to that. I always want to be able to read the docstring in the REPL to know what a function is and how to use it.
2. Relatively slow string parsing (see #8). This is the main blocker for me. (But it's not 'surface level I suppose'.)

However, the really great bits of NanoDates I'd love to use more are:

1. Fast nanosecond-resolution dates and times with full Dates-style interface.
2. Parsing of times with offsets—I usually do this manually at the minute (e.g., here).

Possible things which I would have expected to work differently or might be nice additions.

1. ndnow and ndtoday maybe should default to either UTC or LOCAL with no arguments; it's surprising that this is different from Dates.now and Dates.today. But I guess that may be unavoidable as NanoDates are offset-aware (which is nice).
2. I don't quite know when I might use timestamp over string.
3. It would be nice if a NanoDate constructor could accept a floating-point value for seconds and—as set by a keyword argument—round up or down to the nearest nanosecond. I often find myself doing this manually so it would be a helpful convenience.