SBW timestamp storage sub-optimal for long fuse events

[akrherz]

Consider MEG FL.W 12 for 2024

issue	expire	product_id	polygon_begin	polygon_end	duration
2024-02-12 15:45:00+00	2024-03-03 03:42:00+00	202402110342-KMEG-WGUS44-FLWMEG	2024-02-12 15:45:00+00	2024-02-11 12:36:00+00	-1 days -03:09:00
2024-02-12 01:20:00+00	2024-03-03 12:36:00+00	202402111236-KMEG-WGUS84-FLSMEG	2024-02-11 12:36:00+00	2024-02-12 16:44:00+00	1 day 04:08:00
null	2024-03-04 16:44:00+00	202402121644-KMEG-WGUS84-FLSMEG	2024-02-12 16:44:00+00	2024-02-12 19:52:00+00	03:08:00
null	2024-03-04 19:52:00+00	202402121952-KMEG-WGUS84-FLSMEG	2024-02-12 19:52:00+00	2024-02-13 02:34:00+00	06:42:00
null	2024-03-05 02:34:00+00	202402130234-KMEG-WGUS84-FLSMEG	2024-02-13 02:34:00+00	2024-02-13 18:45:00+00	16:11:00
null	2024-02-18 04:31:00+00	202402131845-KMEG-WGUS84-FLSMEG	2024-02-13 18:45:00+00	2024-02-14 02:09:00+00	07:24:00
null	2024-02-18 00:00:00+00	202402140209-KMEG-WGUS84-FLSMEG	2024-02-14 02:09:00+00	2024-02-14 15:48:00+00	13:39:00
null	2024-02-17 18:00:00+00	202402141548-KMEG-WGUS84-FLSMEG	2024-02-14 15:48:00+00	2024-02-15 03:11:00+00	11:23:00
null	2024-02-17 19:30:00+00	202402150311-KMEG-WGUS84-FLSMEG	2024-02-15 03:11:00+00	2024-02-15 15:58:00+00	12:47:00
null	2024-02-17 19:30:00+00	202402151558-KMEG-WGUS84-FLSMEG	2024-02-15 15:58:00+00	2024-02-16 03:21:00+00	11:23:00
null	2024-02-17 12:00:00+00	202402160321-KMEG-WGUS84-FLSMEG	2024-02-16 03:21:00+00	2024-02-16 16:14:00+00	12:53:00
null	2024-02-17 03:36:00+00	202402161614-KMEG-WGUS84-FLSMEG	2024-02-16 16:14:00+00	2024-02-17 03:36:00+00	11:22:00

There is a lot to hate here.

• we should always avoid the situation of polygon_begin > polygon_end
• perhaps issue and expire should always get updated?
• the dangling expire is problematic as a database query may return it.

[akrherz]

the dangling expire is problematic as a database query may return it.

This is really by design and I should not be querying the database in this manner anyway.