<p>Just a guess, but you might be referring to the <em>POSIX time &lt;-&gt; slot</em> conversion, where Lars noted in week 3 <em>(see notes <a href="https://plutus-pioneer-program.readthedocs.io/en/latest/pioneer/week3.html#scriptcontext" rel="nofollow noreferrer">here</a>)</em>, that - if you require a definite upper bound for a slot interval - you should not place that upper bound too far into the future, because slot lengths could potentially change in the future, and cause your script to behave unexpectedly.</p>
<p>If so, I'm not sure if this is still important in the context of using <em>txInfoValidRange</em> in smart contracts though, since it seems to have changed from SlotRange to POSIXTimeRange (<a href="https://github.com/input-output-hk/plutus/blob/65fa7ce05a810947f565ac59b4d4e35b3cd5d1b3/plutus-ledger-api/src/PlutusLedgerApi/V1/Contexts.hs#L109" rel="nofollow noreferrer">https://github.com/input-output-hk/plutus/blob/65fa7ce05a810947f565ac59b4d4e35b3cd5d1b3/plutus-ledger-api/src/PlutusLedgerApi/V1/Contexts.hs#L109</a> since this <a href="https://github.com/input-output-hk/plutus/commit/7efc96474d3d28fc1d35c1d8a4a3ebe03d651190#diff-7fb2bda211144200604187079d6c51f5be6dcac75e8a2bc2d9b818758c349c3aR108" rel="nofollow noreferrer">commit</a>) - and so you probably don't need to care about this any longer.</p>
<p>In any case this is not related to how long your contract stays on chain, but only how one needs to consider working with time &amp; slot length in certain scenarios.</p>

CC BY-SA 4.0
2022-07-02T22:05:44.760Z
Yeah it's changed a bit can i specify this to be something like 100 years from now?
KryptoKing
CC BY-SA 4.0
2022-07-03T08:31:29.713Z
In general if you're working with the POSIXTime: It's in milliseconds since 1970-01-01T00:00:00Z. So in 100 years it'll be around ~4812480000000. I think in general you can safely work with this in your scripts (but don't trust me on this :p).

However for the "txInfoValidRange" value: It's not set directly by you in posix time, but converted from slots under the hood and set by whoever created the transaction in the first place. I think it can also take any value up to infinity (open interval) - so yes, it can also be a valid tx in 100 years.
sean
CC BY-SA 4.0
2022-07-02T19:46:48.683Z
2022-07-03T08:35:21.233Z
2022-07-03T08:35:21.233Z
sean
<p>In PPP Larz explains that there's a limit to how long a contract can remain on chain, what is that limit and how do I go about extending it?</p>

CC BY-SA 4.0
2022-07-02T18:10:56.163Z
Can you point to the source where Lars says this?
Fermat
<smart-contract><validator><slottime><time><txinfovalidrange>
How to have a contract on chain for extended periods of time?
# How to have a contract on chain for extended periods of time?

(Asked by: username_0 on 2022-07-02)

In PPP Larz explains that there's a limit to how long a contract can remain on chain, what is that limit and how do I go about extending it?

**Tags:** smart-contract, validator, slottime, time, txinfovalidrange
> **Comments:**
> **username_1**: Can you point to the source where Lars says this?  

---

## 1 answers

### Answer by username_2 on 2022-07-02. Score: 2 | Accepted answer

Just a guess, but you might be referring to the *POSIX time <-> slot* conversion, where Lars noted in week 3 *(see notes [here](https://plutus-pioneer-program.readthedocs.io/en/latest/pioneer/week3.html#scriptcontext))*, that - if you require a definite upper bound for a slot interval - you should not place that upper bound too far into the future, because slot lengths could potentially change in the future, and cause your script to behave unexpectedly.

If so, I'm not sure if this is still important in the context of using *txInfoValidRange* in smart contracts though, since it seems to have changed from SlotRange to POSIXTimeRange (<https://github.com/input-output-hk/plutus/blob/65fa7ce05a810947f565ac59b4d4e35b3cd5d1b3/plutus-ledger-api/src/PlutusLedgerApi/V1/Contexts.hs#L109> since this [commit](https://github.com/input-output-hk/plutus/commit/7efc96474d3d28fc1d35c1d8a4a3ebe03d651190#diff-7fb2bda211144200604187079d6c51f5be6dcac75e8a2bc2d9b818758c349c3aR108)) - and so you probably don't need to care about this any longer.

In any case this is not related to how long your contract stays on chain, but only how one needs to consider working with time & slot length in certain scenarios.

> **Comments:**
> **username_0**: Yeah it's changed a bit can i specify this to be something like 100 years from now?  
> **username_2**: In general if you're working with the POSIXTime: It's in milliseconds since 1970-01-01T00:00:00Z. So in 100 years it'll be around ~4812480000000. I think in general you can safely work with this in your scripts (but don't trust me on this :p).  However for the "txInfoValidRange" value: It's not set directly by you in posix time, but converted from slots under the hood and set by whoever created the transaction in the first place. I think it can also take any value up to infinity (open interval) - so yes, it can also be a valid tx in 100 years.  

---

