Jan 31, 4-5 PM (11)
Jan 31, 5-6 PM (4)
Jan 31, 6-7 PM (7)
Jan 31, 7-8 PM (4)
Jan 31, 8-9 PM (6)
Jan 31, 9-10 PM (3)
Jan 31, 10-11 PM (22)
Jan 31, 11-12 AM (20)
Feb 01, 12-1 AM (5)
Feb 01, 1-2 AM (6)
Feb 01, 2-3 AM (9)
Feb 01, 3-4 AM (4)
Feb 01, 4-5 AM (1)
Feb 01, 5-6 AM (0)
Feb 01, 6-7 AM (1)
Feb 01, 7-8 AM (1)
Feb 01, 8-9 AM (1)
Feb 01, 9-10 AM (1)
Feb 01, 10-11 AM (1)
Feb 01, 11-12 PM (3)
Feb 01, 12-1 PM (10)
Feb 01, 1-2 PM (8)
Feb 01, 2-3 PM (29)
Feb 01, 3-4 PM (8)
Feb 01, 4-5 PM (6)
Feb 01, 5-6 PM (4)
Feb 01, 6-7 PM (7)
Feb 01, 7-8 PM (31)
Feb 01, 8-9 PM (19)
Feb 01, 9-10 PM (26)
Feb 01, 10-11 PM (26)
Feb 01, 11-12 AM (18)
Feb 02, 12-1 AM (10)
Feb 02, 1-2 AM (7)
Feb 02, 2-3 AM (7)
Feb 02, 3-4 AM (8)
Feb 02, 4-5 AM (0)
Feb 02, 5-6 AM (4)
Feb 02, 6-7 AM (13)
Feb 02, 7-8 AM (72)
Feb 02, 8-9 AM (29)
Feb 02, 9-10 AM (25)
Feb 02, 10-11 AM (25)
Feb 02, 11-12 PM (27)
Feb 02, 12-1 PM (46)
Feb 02, 1-2 PM (59)
Feb 02, 2-3 PM (36)
Feb 02, 3-4 PM (40)
Feb 02, 4-5 PM (30)
Feb 02, 5-6 PM (11)
Feb 02, 6-7 PM (37)
Feb 02, 7-8 PM (29)
Feb 02, 8-9 PM (21)
Feb 02, 9-10 PM (19)
Feb 02, 10-11 PM (31)
Feb 02, 11-12 AM (32)
Feb 03, 12-1 AM (9)
Feb 03, 1-2 AM (9)
Feb 03, 2-3 AM (14)
Feb 03, 3-4 AM (9)
Feb 03, 4-5 AM (1)
Feb 03, 5-6 AM (3)
Feb 03, 6-7 AM (2)
Feb 03, 7-8 AM (22)
Feb 03, 8-9 AM (63)
Feb 03, 9-10 AM (44)
Feb 03, 10-11 AM (17)
Feb 03, 11-12 PM (27)
Feb 03, 12-1 PM (34)
Feb 03, 1-2 PM (43)
Feb 03, 2-3 PM (48)
Feb 03, 3-4 PM (51)
Feb 03, 4-5 PM (69)
Feb 03, 5-6 PM (20)
Feb 03, 6-7 PM (14)
Feb 03, 7-8 PM (15)
Feb 03, 8-9 PM (14)
Feb 03, 9-10 PM (13)
Feb 03, 10-11 PM (27)
Feb 03, 11-12 AM (20)
Feb 04, 12-1 AM (14)
Feb 04, 1-2 AM (1)
Feb 04, 2-3 AM (5)
Feb 04, 3-4 AM (8)
Feb 04, 4-5 AM (3)
Feb 04, 5-6 AM (8)
Feb 04, 6-7 AM (35)
Feb 04, 7-8 AM (26)
Feb 04, 8-9 AM (56)
Feb 04, 9-10 AM (28)
Feb 04, 10-11 AM (66)
Feb 04, 11-12 PM (75)
Feb 04, 12-1 PM (47)
Feb 04, 1-2 PM (60)
Feb 04, 2-3 PM (59)
Feb 04, 3-4 PM (60)
Feb 04, 4-5 PM (99)
Feb 04, 5-6 PM (54)
Feb 04, 6-7 PM (21)
Feb 04, 7-8 PM (21)
Feb 04, 8-9 PM (11)
Feb 04, 9-10 PM (31)
Feb 04, 10-11 PM (40)
Feb 04, 11-12 AM (29)
Feb 05, 12-1 AM (7)
Feb 05, 1-2 AM (8)
Feb 05, 2-3 AM (9)
Feb 05, 3-4 AM (6)
Feb 05, 4-5 AM (8)
Feb 05, 5-6 AM (16)
Feb 05, 6-7 AM (17)
Feb 05, 7-8 AM (19)
Feb 05, 8-9 AM (28)
Feb 05, 9-10 AM (24)
Feb 05, 10-11 AM (27)
Feb 05, 11-12 PM (41)
Feb 05, 12-1 PM (71)
Feb 05, 1-2 PM (53)
Feb 05, 2-3 PM (22)
Feb 05, 3-4 PM (29)
Feb 05, 4-5 PM (29)
Feb 05, 5-6 PM (32)
Feb 05, 6-7 PM (25)
Feb 05, 7-8 PM (41)
Feb 05, 8-9 PM (36)
Feb 05, 9-10 PM (15)
Feb 05, 10-11 PM (34)
Feb 05, 11-12 AM (27)
Feb 06, 12-1 AM (20)
Feb 06, 1-2 AM (15)
Feb 06, 2-3 AM (14)
Feb 06, 3-4 AM (15)
Feb 06, 4-5 AM (5)
Feb 06, 5-6 AM (11)
Feb 06, 6-7 AM (17)
Feb 06, 7-8 AM (52)
Feb 06, 8-9 AM (91)
Feb 06, 9-10 AM (39)
Feb 06, 10-11 AM (33)
Feb 06, 11-12 PM (42)
Feb 06, 12-1 PM (76)
Feb 06, 1-2 PM (58)
Feb 06, 2-3 PM (52)
Feb 06, 3-4 PM (62)
Feb 06, 4-5 PM (61)
Feb 06, 5-6 PM (13)
Feb 06, 6-7 PM (8)
Feb 06, 7-8 PM (32)
Feb 06, 8-9 PM (12)
Feb 06, 9-10 PM (15)
Feb 06, 10-11 PM (25)
Feb 06, 11-12 AM (29)
Feb 07, 12-1 AM (6)
Feb 07, 1-2 AM (2)
Feb 07, 2-3 AM (5)
Feb 07, 3-4 AM (5)
Feb 07, 4-5 AM (5)
Feb 07, 5-6 AM (7)
Feb 07, 6-7 AM (0)
Feb 07, 7-8 AM (5)
Feb 07, 8-9 AM (7)
Feb 07, 9-10 AM (4)
Feb 07, 10-11 AM (0)
Feb 07, 11-12 PM (0)
Feb 07, 12-1 PM (2)
Feb 07, 1-2 PM (13)
Feb 07, 2-3 PM (15)
Feb 07, 3-4 PM (15)
Feb 07, 4-5 PM (1)
3,867 commits this week Jan 31, 2026 - Feb 07, 2026
fix: use Rust std types in era history types
  Few things are happening in this commit...

  1. TimeMs has been renamed into `SerialisedAsMillis` and
     `SerialisedAsPico`; mostly used as newtype wrapper when serializing
     / deserializing durations. They allow to influence the shape of the
     serialised data according to _what kind of duration_ do they
     represent.

  2. TimeMs, and its replacements, is no longer exposed. We favor
     idiomatic Rust 'Duration' and 'SystemTime' instead. Which means
     that the API of the era history had to slightly change.

  3. The serialisation of the era history has been fixed... there were a
     comment about how the Haskell node encodes some type representing
     seconds with a pico precision, while some other type representing
     durations are encoded and treated as milliseconds. However, the
     code was conflating both scenarios. In fact, we have:

     1. RelativeTime; representing a number of seconds, CBOR-encoded with
	pico precision.

     2. SlotLength; representing a number of milliseconds, and treated
	as such.

     In both cases, we now currently use `Duration`, and handle
     encoding/decoding in a bespoke fashion.

     Note that I think the "better" design would be to introduce proper
     newtypes for the relative time and the slot length, though it is
     more convenient as the moment to rely on Duration as it leads to
     less changes. So perhaps in another iteration.

Signed-off-by: KtorZ <[email protected]>