<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](https://cardano.stackexchange.com/a/7035/6086),

```
> 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.


---

