DM-42227: Switch from datetime to astropy.time in MiddlewareInterface #116
Conversation
This change makes it possible for the patches to refer to individual test cases' environments, in particular their temporary directories.
Some execution paths construct a real ApdbSql object, and the object may attempt to contact the database it represents. Since neither our development and build environments don't have a local PostgreSQL server, use a temporary sqlite DB instead.
astropy.time lets us handle TAI natively, and there's no risk of accidentally giving an unaware datetime. This will also give us more precision when Visit.startTime arrives.
The default is not used by any production code, and both raises the risk of inconsistent collection handling and confuses the program's decision flow.
This prevents the output run code from depending on which time library we use to calculate day_obs; it only needs to know its value.
For consistency with the observing day_obs, the value is defined based on the TAI-12 date of processing start, not the UTC-12 date.
kfindeisen
force-pushed
the
tickets/DM-42227
branch
from
c1ea97f
to
76ae49c
Compare
|
A moment... Still checking if it makes sense to update |
|
To be fully self-consistent, we probably should (if I understand things correctly, the translation between YMD and seconds since epoch is affected by the UTC-TAI offseet). Though it's worth noting that the real T&S code uses a homebrew system on top of |
|
I confirmed that the So.. we (probably I) weren't careful to handle the timestamp as TAI but the the numbers should be fine. And these numbers aren't really used yet. |
The private_sndStamp field is populated by converting an ISO 8601 string to a Unix epoch. To avoid any complications in the future, we should do the conversion in a TAI-aware way.
This PR removes the use of
datetimeinMiddlewareInterfacein favor ofastropy.time, though some unit tests still usedatetimeas the oracle. It also fixes a bug in our tests that was exposed by lsst/dax_apdb#41.