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

lukecampbell commented 10 years ago

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 commented 10 years ago

https://github.com/caseybryant/coverage-model/pull/2

caseybryant commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

ooici / coverage-model

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