You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if zebra displayed a human-readable time or date that coincides with the EoS halt blockheight. This would make it easier for a node operator to be aware of node version update timelines.
Specifications
This is not consensus dependent.
Complex Code or Requirements
The easiest way would be to do a single calculation and just include it statically. This would be least accurate as it would be done some time before that version release is cut and some weeks before the previous version expires (though typically it's not too far off, even at long times in advance).
It could be calculated dynamically; at least initially at startup and optionally re-calculated at some increment, perhaps daily (I think there's room here to play with warning levels, too like 10 days yellow, 5 days red, 1 day blinking! idk). The calculation will likely need to use the block unix timestamps and system time to derive a time/date format.
Testing
Block times vary but currently target 75 seconds. X-checking the time spans doesn't necessarily increase accuracy (it's inherently an estimate) but deriving the seconds remaining, dividing by 60's and 24 and finding that date should never fail.
Related Work
idts!
The text was updated successfully, but these errors were encountered:
Motivation
It would be nice if zebra displayed a human-readable time or date that coincides with the EoS halt blockheight. This would make it easier for a node operator to be aware of node version update timelines.
Specifications
This is not consensus dependent.
Complex Code or Requirements
The easiest way would be to do a single calculation and just include it statically. This would be least accurate as it would be done some time before that version release is cut and some weeks before the previous version expires (though typically it's not too far off, even at long times in advance).
It could be calculated dynamically; at least initially at startup and optionally re-calculated at some increment, perhaps daily (I think there's room here to play with warning levels, too like 10 days yellow, 5 days red, 1 day blinking! idk). The calculation will likely need to use the block unix timestamps and system time to derive a time/date format.
Testing
Block times vary but currently target 75 seconds. X-checking the time spans doesn't necessarily increase accuracy (it's inherently an estimate) but deriving the seconds remaining, dividing by 60's and 24 and finding that date should never fail.
Related Work
idts!
The text was updated successfully, but these errors were encountered: