Fix time metadata in ParticleFile output

[VeckoTheGecko]

Oh yes, if you do

diff --git a/tests/v4/test_particlefile.py b/tests/v4/test_particlefile.py
index 35cd56bf..a3655e3c 100755
--- a/tests/v4/test_particlefile.py
+++ b/tests/v4/test_particlefile.py
@@ -395,8 +395,8 @@ def test_particlefile_write_particle_data(tmp_store):
         time_interval=time_interval,
         time=left,
     )
-    ds = xr.open_zarr(tmp_store, decode_cf=False)  # TODO: Fix metadata and re-enable decode_cf
-    # assert ds.time.dtype == "datetime64[ns]"
-    # np.testing.assert_equal(ds["time"].isel(obs=0).values, left)
+    ds = xr.open_zarr(tmp_store)  # TODO: Fix metadata and re-enable decode_cf
+    assert ds.time.dtype == "datetime64[ns]"
+    np.testing.assert_equal(ds["time"].isel(obs=0).values, left)
     assert ds.sizes["trajectory"] == nparticles
     np.testing.assert_allclose(ds["lon"].isel(obs=0).values, initial_lon)

>               raise type(e)(f"Failed to decode variable {k!r}: {e}") from e
E               ValueError: Failed to decode variable 'time': unable to decode time units 'seconds since 2019-05-30T12:00:00.000000000' with "calendar 'standard'". Try opening your dataset with decode_times=False or installing cftime if it is not installed.

Really have no idea why since the time metadata looks to be valid and the same as other v3 runs which decode properly

{'axis': 'T', 'calendar': 'standard', 'standard_name': 'time', 'units': 'seconds since 2019-05-30T12:00:00.000000000'}

Need to post to xarray still with a minimal reproducer

Originally posted by @VeckoTheGecko in #2142 (comment)

[VeckoTheGecko]

ok, in #2142 I was poking through test_pfile_array_write_zarr_memorystore and found that

{'axis': 'T', 'calendar': 'standard', 'standard_name': 'time', 'units': 'seconds since 2000-01-01T00:00:00.000000000'}

as metadata works with de-serialization. Need to investivate further

[reint-fischer]

I have looked into this because it was an issue for the tutorials I have been rewriting, and I found that xarray decodes into ’NaT’ values from np.iinfo("int64").min, which I assume means it cannot decode the np.iinfo(“uint64").max we are using now as a fill value.

I am making a PR with a simple fix for now, but feel free to chime in with suggestions.