<p>Cadano timestamps are in UTC and your time is almost certainly local time.</p>
<p>Try setting the timezone:</p>
<pre><code>TZ=UTC date &quot;%s&quot;
</code></pre>
<p>As you figured out, <code>getPOSIXTime</code> might be returning millseconds (or maybe even microseconds), whereas the <code>date</code> command is returning seconds.</p>

CC BY-SA 4.0
2022-04-08T12:26:53.197Z
My computer is set to UTC.
https://www.epochconverter.com/ 
says that 1651015217 is some weeks from now. 
I'm guessing my issue is with some config somewhere, but I don't think I changed anything on my node ... or elsewhere...
waalge
CC BY-SA 4.0
2022-04-10T21:29:38.183Z
The chain start time is set in the configuration.
Erik de Castro Lopo
CC BY-SA 4.0
2022-04-11T06:51:17.810Z
Do you mean `scZeroSlotTime`? What should this number be? Neither the value in the example in the repo (1596059091000) , or the number in the linked SE page are close to the value that seems to work. I found no documentation that this number might be different on testnet to mainnet.
waalge
CC BY-SA 4.0
2022-04-11T07:00:15.020Z
Yeah, I think that is it. Its the chain start time, so its usually set to current UTC time and then the chain is started.
Erik de Castro Lopo
CC BY-SA 4.0
2022-04-11T07:27:34.693Z
Hmmm. Not sure I follow. What I ended up doing is in the other answer. I think there is something more fundamentally wrong in my setup. Maybe I'll find out when I move to mainnet 
waalge
CC BY-SA 4.0
2022-04-08T12:01:50.350Z
2022-04-08T12:01:50.350Z
Erik de Castro Lopo
<p>I'm not sure if this will be anyone else's problem or if i've done something uniquely strange. But here's what I did.</p>
<hr />
<p>I had two issues with time
The first was with PAB config.
Finding a better estimate of the zero slot:</p>
<pre><code>$ echo $(($(date +&quot;%s&quot;) - $(cardano-cli query tip ${CARDANO_NODE_MAGIC} | jq '.slot')))
1594369215
</code></pre>
<p>This implies that my <code>pab.yaml</code> config needs to have</p>
<pre><code>...
nodeServerConfig:
    ...
    scSlotZeroTime: 1594369215000
...
</code></pre>
<p>Note this number varies depending on how in sync the node is - but this seemed good enough. It is still weeks different from the example config. Very interested if anyone has an explanation for this.</p>
<p>The second issue was that <code>mustValidateIn</code> seems to have both an on-chain and off-chain interpretation which don't necessarily round-trip.
This is a bit of a pain when used in conjunction with the State Machine framework. Adding more stringent bounds in the off-chain code rectifies  this. Perhaps this problem is an artifact of the slot config above being slightly out.</p>

CC BY-SA 4.0
2022-04-09T14:14:30.170Z
2022-04-09T14:14:30.170Z
waalge
<p>My computer's date command is returning a timestamp wildly different from what testnet wants.</p>
<p>Using <a href="https://cardano.stackexchange.com/a/7035/6086">this formula</a>,</p>
<pre><code>&gt; slotToEndPOSIXTime testnetConf 55047601
POSIXTime {getPOSIXTime = 1651015217999}
</code></pre>
<p>But on my computer</p>
<pre><code>$date &quot;%s&quot;
1649413267
</code></pre>
<p>This is in seconds rather than millisecond, but what might account for the rest of the divergence?</p>

<plutus><plutus-pioneer-program><slottime><time><posixtime>
Diagnosing a POSIXTime discrepancy
# Diagnosing a POSIXTime discrepancy

(Asked by: username_0 on 2022-04-08)

My computer's date command is returning a timestamp wildly different from what testnet wants.
Using this formula,
> slotToEndPOSIXTime testnetConf 55047601
POSIXTime {getPOSIXTime = 1651015217999}

But on my computer
$date "%s"
1649413267

This is in seconds rather than millisecond, but what might account for the rest of the divergence?

**Tags:** plutus, plutus-pioneer-program, slottime, time, posixtime

---

## 2 answers

### Answer by username_1 on 2022-04-08. Score: 0

Cadano timestamps are in UTC and your time is almost certainly local time.
Try setting the timezone:
TZ=UTC date "%s"

As you figured out, getPOSIXTime might be returning millseconds (or maybe even microseconds), whereas the date command is returning seconds.

> **Comments:**
> **username_0**: My computer is set to UTC. https://www.epochconverter.com/  says that 1651015217 is some weeks from now.  I'm guessing my issue is with some config somewhere, but I don't think I changed anything on my node ... or elsewhere...  
> **username_1**: The chain start time is set in the configuration.  
> **username_0**: Do you mean `scZeroSlotTime`? What should this number be? Neither the value in the example in the repo (1596059091000) , or the number in the linked SE page are close to the value that seems to work. I found no documentation that this number might be different on testnet to mainnet.  
> **username_1**: Yeah, I think that is it. Its the chain start time, so its usually set to current UTC time and then the chain is started.  
> **username_0**: Hmmm. Not sure I follow. What I ended up doing is in the other answer. I think there is something more fundamentally wrong in my setup. Maybe I'll find out when I move to mainnet   

---

### Answer by username_0 on 2022-04-09. Score: 0

I'm not sure if this will be anyone else's problem or if i've done something uniquely strange. But here's what I did.

I had two issues with time
The first was with PAB config.
Finding a better estimate of the zero slot:
$ echo $(($(date +"%s") - $(cardano-cli query tip ${CARDANO_NODE_MAGIC} | jq '.slot')))
1594369215

This implies that my pab.yaml config needs to have
...
nodeServerConfig:
    ...
    scSlotZeroTime: 1594369215000
...

Note this number varies depending on how in sync the node is - but this seemed good enough. It is still weeks different from the example config. Very interested if anyone has an explanation for this.
The second issue was that mustValidateIn seems to have both an on-chain and off-chain interpretation which don't necessarily round-trip.
This is a bit of a pain when used in conjunction with the State Machine framework. Adding more stringent bounds in the off-chain code rectifies  this. Perhaps this problem is an artifact of the slot config above being slightly out.


---

