<p>You did not account for Byron, where one slot was 20 seconds.</p>
<p>To make it easier, take the start time of epoch 209 which is the Shelley hardfork and started at <code>1596491091</code> unix time on slot <code>4924800</code>.</p>
<p>Therefore to calculate the time of the current slot, you might try something like: <code>1596491091 + (current_slot - 4924800)</code>.</p>

CC BY-SA 4.0
2021-05-20T06:44:11.770Z
thank you, is this timestamp documented anywhere?
wutzebaer
CC BY-SA 4.0
2021-05-21T12:49:13.703Z
Not directly documented, it's on chain, I used blockfrost to retrieve it: https://cardano-mainnet.blockfrost.io/api/v0/epochs/209 (need blockfrost.io token).
Marek Mahut - StakeNuts
CC BY-SA 4.0
2021-05-28T20:28:46.093Z
Hi i cannot accept your answer, because if i calculate `1596491091+29786450=1626277541 => 14.07.2021 - 17:45:41` which is far away from `Tue 18 May` what am i doing wrong?
wutzebaer
CC BY-SA 4.0
2021-05-28T20:36:17.777Z
Oh right, the epoch 209 started on slot `4924800`. So you need to do: `1596491091+(current_slot - 4924800)`, I have edited my answer to mention this.
Marek Mahut - StakeNuts
CC BY-SA 4.0
2021-05-28T20:52:01.580Z
looks good, thank you
wutzebaer
CC BY-SA 4.0
2022-01-30T12:04:32.227Z
Hi, I'm trying to do the same thing in testnet. What unix-time/slot should I use  for testnet ? Thanks in advance.
kindofdev
CC BY-SA 4.0
2021-05-18T20:53:40.670Z
2021-11-24T13:45:12.270Z
2021-11-24T13:45:12.270Z
Marek Mahut - StakeNuts
<p>Note this answer could change if a hard fork changes parameters.</p>
<p>The Shelly unix time is the start time of the Shelly era and the Shelly slot is the corresponding slot. We use these values to ignore the Bryon era (with odd slot value).</p>
<p><strong>Calculate a slot:</strong> (returns the Cardano slot)</p>
<pre><code>UNIX_TARGET_TIME - 1596491091+ 4924800
</code></pre>
<p><strong>Check a slot:</strong> (returns unix timestamp)</p>
<pre><code>1596491091 + (SLOT - 4924800)
</code></pre>
<p><strong>Python example:</strong></p>
<pre><code>from datetime import datetime

SHELLY_UNIX = 1596491091
SHELLY_SLOT = 4924800

def getSlotFromUnixTime(ut):
    return ut - SHELLY_UNIX + SHELLY_SLOT

def getUTCEstimateFromSlot(slot):
    ts = SHELLY_UNIX + (slot - SHELLY_SLOT)
    print(datetime.utcfromtimestamp(ts).strftime('%Y-%m-%d %H:%M:%S'))
</code></pre>
<p>source code: <a href="https://github.com/pixel-pool/PythonCardanoSlotsScript" rel="nofollow noreferrer">https://github.com/pixel-pool/PythonCardanoSlotsScript</a></p>

CC BY-SA 4.0
2022-06-10T18:33:52.863Z
2022-06-10T18:33:52.863Z
Jack
<p><strong>Calculating a timestamp from a slot number is risky!</strong><br>
Theoretically, the slot duration could be changed by a hard fork for example because of performance reasons (as has already happened). So it's probably best to use an oracle for now.</p>
<p>But because time is used so frequently, it would probably be best if Cardano would support a more reliable native solution that avoids oracle fees.</p>

CC BY-SA 4.0
2021-05-22T08:44:28.547Z
ok thank you i thought slotnumbers were a reliable timestamp
wutzebaer
CC BY-SA 4.0
2021-05-23T08:46:50.807Z
That is very unlikely. This is the reason that the coefficient number was introduced. This parameter will be used to tune the network pace, not the slot number. The reason for the change in Shelley was this exact bad design, that is now fixed.
Marek Mahut - StakeNuts
CC BY-SA 4.0
2021-11-24T17:21:35.847Z
Also, Cardano will likely lean into having to use an oracle, as evidenced by their explicit relying on a random global oracle for Ouroboros Chronos, and their overall trend towards distributed systems, not just distributed payment channels.
zhekson
CC BY-SA 4.0
2021-05-21T20:01:32.700Z
2021-05-22T16:43:51.963Z
2021-05-22T16:43:51.963Z
Johannes Sirsch
<p>Is it possible to calculate a timestamp from a slot no? Since one slot is one second it should be pretty easy. But...</p>
<p>The current slot now (<code>Tue 18 May 2021 05:46:04 PM CEST</code>) is <code>29786450</code>.</p>
<p>In mainnet-shelley-genesis.json i can see <code>systemStart  &quot;2017-09-23T21:44:51Z&quot;</code></p>
<p>Which is acually 1506203091 as unix timestamp.</p>
<p>If i calculate <code>1506203091 + 29786450</code> i get <code>1535989541</code> which is <code>Sep 3, 2018, 5:45:41 PM</code> something in 2018.</p>
<p>Is there a simple formular? It seems that the actual start date must be something like <code>June 7, 2020</code> but i cannot find anything abount this date.</p>

<slottime>
Calculate timestamp from slot
# Calculate timestamp from slot

(Asked by: username_0 on 2021-05-18)

Is it possible to calculate a timestamp from a slot no? Since one slot is one second it should be pretty easy. But...

The current slot now (`Tue 18 May 2021 05:46:04 PM CEST`) is `29786450`.

In mainnet-shelley-genesis.json i can see `systemStart "2017-09-23T21:44:51Z"`

Which is acually 1506203091 as unix timestamp.

If i calculate `1506203091 + 29786450` i get `1535989541` which is `Sep 3, 2018, 5:45:41 PM` something in 2018.

Is there a simple formular? It seems that the actual start date must be something like `June 7, 2020` but i cannot find anything abount this date.

**Tags:** slottime

---

## 3 answers

### Answer by username_1 on 2021-05-18. Score: 10 | Accepted answer

You did not account for Byron, where one slot was 20 seconds.

To make it easier, take the start time of epoch 209 which is the Shelley hardfork and started at `1596491091` unix time on slot `4924800`.

Therefore to calculate the time of the current slot, you might try something like: `1596491091 + (current_slot - 4924800)`.

> **Comments:**
> **username_0**: thank you, is this timestamp documented anywhere?  
> **username_1**: Not directly documented, it's on chain, I used blockfrost to retrieve it: https://cardano-mainnet.blockfrost.io/api/v0/epochs/209 (need blockfrost.io token).  
> **username_0**: Hi i cannot accept your answer, because if i calculate `1596491091+29786450=1626277541 => 14.07.2021 - 17:45:41` which is far away from `Tue 18 May` what am i doing wrong?  
> **username_1**: Oh right, the epoch 209 started on slot `4924800`. So you need to do: `1596491091+(current_slot - 4924800)`, I have edited my answer to mention this.  
> **username_0**: looks good, thank you  
> **username_2**: Hi, I'm trying to do the same thing in testnet. What unix-time/slot should I use  for testnet ? Thanks in advance.  

---

### Answer by username_3 on 2022-06-10. Score: 2

Note this answer could change if a hard fork changes parameters.
The Shelly unix time is the start time of the Shelly era and the Shelly slot is the corresponding slot. We use these values to ignore the Bryon era (with odd slot value).
Calculate a slot: (returns the Cardano slot)
UNIX_TARGET_TIME - 1596491091+ 4924800

Check a slot: (returns unix timestamp)
1596491091 + (SLOT - 4924800)

Python example:
from datetime import datetime

SHELLY_UNIX = 1596491091
SHELLY_SLOT = 4924800

def getSlotFromUnixTime(ut):
    return ut - SHELLY_UNIX + SHELLY_SLOT

def getUTCEstimateFromSlot(slot):
    ts = SHELLY_UNIX + (slot - SHELLY_SLOT)
    print(datetime.utcfromtimestamp(ts).strftime('%Y-%m-%d %H:%M:%S'))

source code: https://github.com/pixel-pool/PythonCardanoSlotsScript


---

### Answer by username_4 on 2021-05-21. Score: 1

**Calculating a timestamp from a slot number is risky!**  
Theoretically, the slot duration could be changed by a hard fork for example because of performance reasons (as has already happened). So it's probably best to use an oracle for now.

But because time is used so frequently, it would probably be best if Cardano would support a more reliable native solution that avoids oracle fees.

> **Comments:**
> **username_0**: ok thank you i thought slotnumbers were a reliable timestamp  
> **username_1**: That is very unlikely. This is the reason that the coefficient number was introduced. This parameter will be used to tune the network pace, not the slot number. The reason for the change in Shelley was this exact bad design, that is now fixed.  
> **username_5**: Also, Cardano will likely lean into having to use an oracle, as evidenced by their explicit relying on a random global oracle for Ouroboros Chronos, and their overall trend towards distributed systems, not just distributed payment channels.  

---

