Open epag opened 3 weeks ago
Original Redmine Comment Author Name: James (James) Original Date: 2021-09-14T14:08:39Z
See #96190-12 onwards.
Original Redmine Comment Author Name: Chris (Chris) Original Date: 2021-09-14T14:18:14Z
|\3. Date Ranges | |. Tech |. Minimum Date |_. Maximum Date | | Postgres | 4713-01-01T00:00:00+0000 BC | 294276-12-31T23:59:59+0000 | | Python | 0001-01-01T00:00:00+0000 | 9999-12-31T23:59:59+0000 |
Original Redmine Comment Author Name: James (James) Original Date: 2021-09-14T14:20:56Z
Useful, thanks. Those python bounds are surprising. Is that core python or whatever you call it?
Original Redmine Comment Author Name: James (James) Original Date: 2021-09-14T14:21:53Z
I mean, no paleontological time-series in Python, I guess, at least not as times :)
Original Redmine Comment Author Name: Chris (Chris) Original Date: 2021-09-14T14:22:28Z
Yeah, that's vanilla. The Numpy ranges are probably greater due to them being implemented in C or Fortran, not python.
Original Redmine Comment Author Name: Chris (Chris) Original Date: 2021-09-14T14:34:38Z
It looks like numpy can handle [9200000000000000000 BC, 9200000000000000000 AD].
Original Redmine Comment Author Name: James (James) Original Date: 2021-09-14T14:36:06Z
Ha, that should be wide enough :) ( Still, we should change it. )
Author Name: James (James) Original Redmine Issue: 96218, https://vlab.noaa.gov/redmine/issues/96218 Original Date: 2021-09-14
Given an evaluation that writes pairs or statistics When the pools are described for an unbounded time dimension Then most software applications used by real users should be able to read them
Examples of languages: python applications, R applications, bash applications etc.
( Some applications can handle things like @+1000000000-12-31T23:59:59.999999999Z@, such as java and bash applications, others cannot so easily, such as python, apparently. )