Can't observe data after 2036-02-07T06:28:15

[lukecampbell]

For observations made after that date the following error is raised:

   ----- exception: 'I' format requires 0 <= number <= 4294967295 -----
tion/science_granule_ingestion_worker.py:459    self.add_granule(stream_id, rdt)
tion/science_granule_ingestion_worker.py:617    self.insert_values(coverage, rdt, stream_id)
tion/science_granule_ingestion_worker.py:535    coverage.set_parameter_values(np_dict)
overage-model/coverage_model/coverage.py:554    self._persistence_layer.write_parameters(self.get_write_id(), values)
l/storage/parameter_persisted_storage.py:263    span_table.write_span(span)
e_model/storage/postgres_span_storage.py:52     stats_sql, bin_sql = self.get_span_stats_and_bin_insert_sql(span)
e_model/storage/postgres_span_storage.py:74     time_min = PostgresDB._get_time_string(span_stats[time_db_key][0])
ge-model/coverage_model/db_connectors.py:239    ntp_time = struct.pack(IonTime.ntpv4_timestamp, i, d)

[lukecampbell]

caseybryant#2

[caseybryant]

At that date, we're looking at NTP rollover/end of era. Isn't this a global problem that needs to be resolved? Shouldn't we really be looking at building a project time class that can handle NTP rollover and accurately compare data across eras?

But I appreciate your confidence in the software longevity.

[lukecampbell]

We can leave this issue as outstanding. 2038 is the unix time bug where all systems that implement time_t as a int32_t will have an integer overflow. I guess 2036 is the NTP one, and NTP probably uses a uint_32 but the epoch is 1900.

[lukecampbell]

Promoted to JIRA bug: https://jira.oceanobservatories.org/tasks/browse/OOIION-1862