Fix time encoding to use int64 and "nanoseconds since 1970-01-01 00:00:00Z"

[ctuguinay]

This PR addresses the not faithful time serialization warning from issue #1290.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 90.00000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 74.57%. Comparing base (9f56124) to head (900ae7d).
Report is 44 commits behind head on main.

Files	Patch %	Lines
echopype/utils/coding.py	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1299      +/-   ##
==========================================
- Coverage   83.52%   74.57%   -8.95%     
==========================================
  Files          64       23      -41     
  Lines        5686     3182    -2504     
==========================================
- Hits         4749     2373    -2376     
+ Misses        937      809     -128     

Flag	Coverage Δ
unittests	74.57% <90.00%> (-8.95%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ctuguinay]

Explanation of the current warning (from slack conversation)

@leewujung

Here's the current order of events in the code that is causing this warning: (https://github.com/pydata/xarray/blob/1d43672574332615f225089d69f95a9f8d81d912/xarray/coding/times.py#L723C1-L803C32):

1. The computation converts nanosecond resolution time to int64.

2. Computes needed time time_delta (represents the time unit granularity based on the specified units), and needed_time_delta (represents the minimum unit granularity required for lossless integer encoding of the dates).

3. (Optional) If time_delta > needed_time_delta, and we specify None dtype encoding we get the not faithful serialization message, since with integer bit 64 encoding, we will lose precision.

4. The operation to finalize the encoding is then done in int64.

5. (Optional) Then, if we actually specify dtype, we cast to dtype (if numpy deems safe).

Now, I am not quite sure at this point why float64 should silence this warning: The casting to float64 is a bit of a 'moot point', since the casting operation is done post-encoding computation, which we know will result in lossful integer encoding.
This is probably why None and float64 encoding result in the same values. The float64 dtype does practically nothing to change the encoded array, since it is done at the very last step. Additionally, the time_delta > needed_time_delta also is why we lose precision even when there is no warning (in the case where we set dtype set to float64).

Perhaps this is an issue I bring up in xarray? This still doesn't make sense to me, but I do think it'd be good to silence this error as soon as possible since it can be very disheartening seeing so many time serialization warnings on your first use of Echopype.

On our own end, do you think adding a warning in the logger for this would be a good idea? That way those users that have logger verbose turned on can still get the message.

[leewujung]

@ctuguinay : Looks great! I am glad we got this resolved after much digging and trial and error!

I only have one comment: What do you think of changing the function name _encode_dataarray to _encode_time_dataarray? Since it is only used for set_time_encodings and the content does not make sense for other types of dataarray?

Otherwise I think this is good to go.

[ctuguinay]

@leewujung Made that change. This should be ready to merge now