Upcoming changes

From the 2022 collaboration meeting

1. Internal (payload) representation of event times:
   1. absolute: ns since Unix epoch (generally needs something with 64 bits)
   2. relative: ns
2. For other times, such as arguments, need to document the intended units.
3. TimeSeries and TimeHist will subclass a new TimeCurve class. (Note TimeHist also subclasses Hist1D.)
   1. TimeCurve will have a reference time, which is absolute.
   2. TimeCurve will have (optional) start and stop times, which are relative to the reference time.
   3. If start and stop times are given for objects which can be indeterminate (such as TimeSeries), events outside the limits will not be saved but simply be counted as underflows and overflows.

Other practices I've found useful:

1. There's a new library routine in snewpdag.dag.lib called fetch_field, which gets a field from a given dictionary.
   1. if the field name is a simple string, it'll check that the field exists in the dictionary and fetch it directly. If the field doesn't exist, it returns False as the second return value.
   2. if the field name is a tuple or list, it works its way down the dictionary by those names. You can also use integers to reference list elements.
   3. the second return value is a boolean which indicates whether the field was found or not. If the field wasn't found, the first return value isn't defined. This behavior may change to returning a user-defined default value instead.
   4. I'd recommend using fetch_field whenever you look up things in the payload. In particular, if you have a module argument which specifies a field (such as in_field or out_field), using fetch_field is easy and more flexible.
2. Some numerical module arguments could be given in the configuration file, or in the payload, e.g., a bias or uncertainty. You can allow either possibility by testing the type of the argument: if it's a number, use that value. If it's a field designation (string or tuple or list), then read the value from the payload.
3. It's not uncommon for utility modules to be needed for alerts or reports, depending on the circumstance. Introduce an argument 'on' which takes a list of strings, e.g., ['alert','report']. That would respond to both.