-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Cli: add cluster-date subcommand, and make block-time slot optional #9878
Cli: add cluster-date subcommand, and make block-time slot optional #9878
Conversation
e813f05
to
419a227
Compare
419a227
to
89b6eed
Compare
I don't understand the difference between |
89b6eed
to
5fa13f3
Compare
Well, I am not clear on why the validator timestamp oracle was not appropriate for lockup timestamp needs, but we do have 2 sources of timestamps, and @mvines suggested the |
23aba77
to
f4ed1cf
Compare
Got it, thanks. LGTM |
Codecov Report
@@ Coverage Diff @@
## master #9878 +/- ##
========================================
- Coverage 80.4% 80.4% -0.1%
========================================
Files 283 283
Lines 64936 64977 +41
========================================
- Hits 52245 52242 -3
- Misses 12691 12735 +44 |
Problem
The cluster calculates the date as a function of slots from genesis, and it uses that date to determine if a stake account is locked. If we want to set an unlock for something like "one day from now", there's no RPC endpoint to ask the cluster what it thinks "now" is.
Summary of Changes
solana cluster-date
command to returnsysvar::Clock.unix_timestamp
from the most recent cluster-confirmed rootsolana block-time
slot param optional, and returngetBlockTime
from the most recent cluster-confirmed root if None--output json
available for both commandsOof, almost a week difference (cc #9874 )
Fixes #9847