Hi
we just opened the vote on the “let construct (Block Scoping)” RFC
(which was originally proposed as “use construct”, but the keyword
changed as a result of the discussion).
Please find the following resources:
- RFC: https://wiki.php.net/rfc/optin_block_scoping
- Official Discussion Thread:
https://news-web.php.net/php.internals/129059 - Related Discussion Thread:
https://news-web.php.net/php.internals/129251
There is one primary vote to cast on the RFC. Voting will run for 2
weeks until 2026-02-05 09:30 UTC.
Best regards
Tim Düsterhus
Hi
we just opened the vote on the “let construct (Block Scoping)” RFC
(which was originally proposed as “use construct”, but the keyword
changed as a result of the discussion).
I have voted No.
I really want block scoping as a feature in PHP, but I do not want this
syntax.
For those who didn't follow the discussion thread, I will try to
summarise my reasons:
-
I don't think PHP is special enough to break with a strong tradition
here. A huge family of languages use roughly the same syntax for
variable declarations, even though they have very different details of
how they work. That includes C and Java, but also JS and Perl, and even
VisualBasic (all ultimately traceable to ALGOL). -
Users are likely to be coming from those related languages,
particularly JS, and are likely to be confused by how this syntax works. -
For instance, they would not expect a comma-separated list to be
equivalent to a set of nested blocks, which affects the behaviour of
cases like let($a=new Foo, $a=new Bar) -
The use cases for combining with "if" or "foreach" are interesting,
but the result is confusing - the important control flow keyword ends up
in the middle of the line. -
For other use cases, requiring an extra block adds noise. For
instance, if we ever add auto-capture closures, a JS-style a concise
block-scoped declaration would be very useful to avoid accidental capture.
PHP itself already has "ALGOL-style" declarations, for "const",
"global", and "static". I think adding a "let" or "var" keyword with the
same syntax would be more consistent, and more useful.
There would be details to work out, but dozens of other languages to
learn from.
My thanks to Seifeddine and Tim for their work on this, and to Tim in
particular for patient and respectful discussion.
--
Rowan Tommins
[IMSoP]
On Thu, Jan 22, 2026, 12:12 Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
wrote:
Hi
we just opened the vote on the “let construct (Block Scoping)” RFC
(which was originally proposed as “use construct”, but the keyword
changed as a result of the discussion).I have voted No.
I really want block scoping as a feature in PHP, but I do not want this
syntax.For those who didn't follow the discussion thread, I will try to
summarise my reasons:
I don't think PHP is special enough to break with a strong tradition
here. A huge family of languages use roughly the same syntax for
variable declarations, even though they have very different details of
how they work. That includes C and Java, but also JS and Perl, and even
VisualBasic (all ultimately traceable to ALGOL).Users are likely to be coming from those related languages,
particularly JS, and are likely to be confused by how this syntax works.For instance, they would not expect a comma-separated list to be
equivalent to a set of nested blocks, which affects the behaviour of
cases like let($a=new Foo, $a=new Bar)The use cases for combining with "if" or "foreach" are interesting,
but the result is confusing - the important control flow keyword ends up
in the middle of the line.For other use cases, requiring an extra block adds noise. For
instance, if we ever add auto-capture closures, a JS-style a concise
block-scoped declaration would be very useful to avoid accidental capture.PHP itself already has "ALGOL-style" declarations, for "const",
"global", and "static". I think adding a "let" or "var" keyword with the
same syntax would be more consistent, and more useful.There would be details to work out, but dozens of other languages to
learn from.My thanks to Seifeddine and Tim for their work on this, and to Tim in
particular for patient and respectful discussion.--
Rowan Tommins
[IMSoP]
I agree, the proposed syntax and nested block hell are terrible!
The traditional syntax with implicit and invisible nested block are much
better, many languages and years of trusting proved that.
Hi
we just opened the vote on the “let construct (Block Scoping)” RFC
(which was originally proposed as “use construct”, but the keyword
changed as a result of the discussion).
Hi,
Thank you for your work on this.
I voted no because the RFC is presented as a way to dispose of
resources immediately (quoting: "This feature provides immense value,
particularly for modern applications built on long-lived servers,
where disciplined and immediate resource cleanup is not just a best
practice, but a necessity for stability and performance."), yet it
doesn't in practice as it relies on reference counting as a proxy for
cleaning up at block exit.
While reference counting is deterministic, ensuring that a value is
uniquely referenced before leaving a block is impossible, and cannot
be enforced by the block itself. In practice, useful code will send
the resource to other functions or 3rd party code that may retain a
reference to it. Moreover, there are many non-obvious ways in which a
reference count can be increased or a value’s lifetime extended:
exceptions or backtraces may capture arguments, fibers, generators, or
closures with non obvious lifetimes retain their local variables,
closures tend to create cycles, foreach variables are not always
unset, etc.
Therefore there is a non-zero possibility that a let() statement will
not in fact cleanup the resource, despite the stated goal. Fixing this
later would be a BC break as people may rely on this behavior.
The RFC refers to similar constructs from other languages, but none of
them rely on reference counting for this purpose. I'm not aware of
languages relying on reference counting for this.
Best Regards,
Arnaud
Am 22.01.2026, 18:57:04 schrieb Arnaud Le Blanc arnaud.lb@gmail.com:
Hi
we just opened the vote on the “let construct (Block Scoping)” RFC
(which was originally proposed as “use construct”, but the keyword
changed as a result of the discussion).
Hi,
Thank you for your work on this.
I voted no because the RFC is presented as a way to dispose of
resources immediately (quoting: "This feature provides immense value,
particularly for modern applications built on long-lived servers,
where disciplined and immediate resource cleanup is not just a best
practice, but a necessity for stability and performance."), yet it
doesn't in practice as it relies on reference counting as a proxy for
cleaning up at block exit.
I agree that relying on reference counting can bite you, but I still voted
Yes, because
- We only have reference counting to rely on in PHP as far as memory
goes, and thats what people writing cleanup critical code rely on already.
This gives a much nicer syntax. - The future scope lists improvements as next steps, like the error when
RC > 1 or Disposable interfaces, this is a first step towards something
that is missing dearly.
While reference counting is deterministic, ensuring that a value is
uniquely referenced before leaving a block is impossible, and cannot
be enforced by the block itself. In practice, useful code will send
the resource to other functions or 3rd party code that may retain a
reference to it. Moreover, there are many non-obvious ways in which a
reference count can be increased or a value’s lifetime extended:
exceptions or backtraces may capture arguments, fibers, generators, or
closures with non obvious lifetimes retain their local variables,
closures tend to create cycles, foreach variables are not always
unset, etc.Therefore there is a non-zero possibility that a let() statement will
not in fact cleanup the resource, despite the stated goal. Fixing this
later would be a BC break as people may rely on this behavior.The RFC refers to similar constructs from other languages, but none of
them rely on reference counting for this purpose. I'm not aware of
languages relying on reference counting for this.Best Regards,
Arnaud
Hi,
On Fri, Jan 23, 2026 at 10:59 AM Benjamin Außenhofer
kontakt@beberlei.de wrote:
I agree that relying on reference counting can bite you, but I still voted Yes, because
We only have reference counting to rely on in PHP as far as memory goes
For disposal, only if we decide so. The RFC proposes to introduce
block scoping, and could have made the decision to deterministically
dispose of values as they go out of scope.
The RFC refers to similar features in Python and Hack, with the same
basic syntax, both of which use reference counting as primary garbage
collection mechanism, yet disposal is deterministic in this context.
and thats what people writing cleanup critical code rely on already. This gives a much nicer syntax.
In my experience, relying on this causes occasional bugs that are
unusually difficult to address (and to avoid in the first place).
The future scope lists improvements as next steps, like the error when RC > 1 or Disposable interfaces, this is a first step towards something that is missing dearly.
Unfortunately these improvements won't make it because they will be
breaking changes.
Best Regards,
Arnaud
Hi
Reordering the quoted parts to improve the structure of the reply.
Am 2026-01-24 15:13, schrieb Arnaud Le Blanc:
and thats what people writing cleanup critical code rely on already.
This gives a much nicer syntax.In my experience, relying on this causes occasional bugs that are
unusually difficult to address (and to avoid in the first place).
The RFC lists 4 possible use cases within the example section:
a) Example showing an edge case (solving the foreach reference bug)
Here the goal is not to destruct the underlying value, but to free up
the variable name for reuse.
b) Example showing the combination of let and if()
The same applies here. The goal is to prevent accidental use of a
variable after it is no longer meant to be used. The stored value will
not have special destruction logic attached.
c) Example showing memory-efficient batch processing
For this one the concern is "memory consumption". To my understanding
you considered this a safe use case for reference counting in
https://news-web.php.net/php.internals/129189.
d) Example showing reliable resource management
This leaves the locking example, where the object guards a non-memory
resource that might accidentally be captured. In my experience
developing PHP, I never had an issue with accidental escapes of resource
objects and I feel that keeping them in a local variable is sufficiently
robust to prevent them from accidentally being captured.
I acknowledge that your experience was different than mine, that's why
the RFC lists possible improvements to make this easier/safer as future
scope.
The RFC proposes a generically applicable language feature that solves
example use cases (a), (b), (c) perfectly fine as-is. It is no worse
than existing solutions for (d) and leaves a clear path for future scope
ideas to support (d) even better. I feel that reducing it to just the
"lock example" / "external resource management" is not doing the RFC
justice.
The future scope lists improvements as next steps, like the error when
RC > 1 or Disposable interfaces, this is a first step towards
something that is missing dearly.Unfortunately these improvements won't make it because they will be
breaking changes.
This is false. We would not list anything as "Future Scope" when it
would be a breaking change. Both the RC > 1 and the Disposable interface
would require the author of the resource class to add an interface for
the corresponding functionality to become active and would therefore be
fully opt-in. Adding new symbols (incl. interfaces) to PHP is not
considered a breaking change as per our policy:
https://github.com/php/policies/blob/main/release-process.rst#backward-compatibility.
Throwing for every RC > 1 object at the end of the let() block would
break the "let ($user = $repository->find(1)) if ($user !== null)" use
case if the repository internally uses an identity map and thus keeps a
reference to all objects it hands out. Any special Disposable handling
for a user object would also break the identity map, because it now
stores an object that already was disposed and thus likely is in an
invalid state.
For disposal, only if we decide so. The RFC proposes to introduce
block scoping, and could have made the decision to deterministically
dispose of values as they go out of scope.
See above: This would possibly break at least one of the presented use
cases of the RFC.
The RFC refers to similar features in Python and Hack, with the same
basic syntax, both of which use reference counting as primary garbage
collection mechanism, yet disposal is deterministic in this context.
The "References" section is non-normative with regard to the proposal
itself and just supplies supplementary information. My previous email
provides further context to the listed references:
https://news-web.php.net/php.internals/129202.
Best regards
Tim Düsterhus
Hi,
Le sam. 24 janv. 2026 à 18:35, Tim Düsterhus tim@bastelstu.be a écrit :
Am 2026-01-24 15:13, schrieb Arnaud Le Blanc:
and thats what people writing cleanup critical code rely on already.
This gives a much nicer syntax.In my experience, relying on this causes occasional bugs that are
unusually difficult to address (and to avoid in the first place).The RFC lists 4 possible use cases within the example section:
I agree that the RFC adresses 3 of these use cases, but I regret that the
pitfall in the last one is being dismissed or minimized, while claiming to
address that use case. There is enough evidence in other languages that the
pitfall is real and common, as features claiming to address the use case
are designed explicitly to avoid it.
This leaves the locking example
This is a simple one, but most code will send the scoped resource to other
functions to perform anything useful, increasing the risk of capture.
The future scope lists improvements as next steps, like the error when
RC > 1 or Disposable interfaces, this is a first step towards
something that is missing dearly.
Unfortunately these improvements won't make it because they will be
breaking changes.This is false. We would not list anything as "Future Scope" when it
would be a breaking change. Both the RC > 1 and the Disposable interface
would require the author of the resource class to add an interface for
the corresponding functionality to become active and would therefore be
fully opt-in. Adding new symbols (incl. interfaces) to PHP is not
considered a breaking change as per our policy:https://github.com/php/policies/blob/main/release-process.rst#backward-compatibility
.
The issue is that implementing Disposable on existing objects after the
fact is a BC break as by then some code may rely on the fact that disposal
is not enforced. This precludes making any exiting object (or streams)
Disposable if that interface is introduced later, because this might break
people’s code. Making it opt-in in the let() syntax is a potential solution
to that, but it’s error prone.
For disposal, only if we decide so. The RFC proposes to introduce
block scoping, and could have made the decision to deterministically
dispose of values as they go out of scope.See above: This would possibly break at least one of the presented use
cases of the RFC.
As you said this would be opted in by implementing Disposable.
The RFC refers to similar features in Python and Hack, with the same
basic syntax, both of which use reference counting as primary garbage
collection mechanism, yet disposal is deterministic in this context.The "References" section is non-normative with regard to the proposal
itself and just supplies supplementary information. My previous email
provides further context to the listed references:
https://news-web.php.net/php.internals/129202.
I know, but making comparisons is natural as the RFC claims to address the
same use cases. Based on the previous thread it feels like the design was
adapted to borrow principles from Rust (objects can be disposed only when
unreachable), but PHP doesn’t have features that would make this reliable,
like explicit lifetimes. I think that the way that languages closer to
PHP implement this use case would fit PHP better.
Best Regards,
Arnaud
While I appreciate all of the hard work that Seifeddine and you put into this RFC, Tim, if I had the power to vote, I would vote "No" on this RFC as I like the approach laid out in the Context Manager RFC much better.. Thank you both!
Hi
Am 2026-01-23 00:29, schrieb Joseph Leedy:
While I appreciate all of the hard work that Seifeddine and you put
into this RFC, Tim, if I had the power to vote, I would vote "No" on
this RFC as I like the approach laid out in the Context Manager RFC
much better.. Thank you both!
I'd like to note that while the two RFCs share some of the scope,
neither is a direct replacement of the other. I think Rowan previously
summarized it well in this email:
https://news-web.php.net/php.internals/129630.
The focus of the “let construct (Block Scoping)” RFC is enabling block
scoping - as the name implies. The examples in the “Examples” section of
the RFC are intended to reflect some real-world situations where either
Seifeddine or I would've liked to have block scoping. Except for the
“process_file()” example, I don't believe the Context Manager RFC (as
currently proposed) would be a suitable replacement.
Best regards
Tim Düsterhus
Hi
Am 2026-01-23 00:29, schrieb Joseph Leedy:
While I appreciate all of the hard work that Seifeddine and you put
into this RFC, Tim, if I had the power to vote, I would vote "No" on
this RFC as I like the approach laid out in the Context Manager RFC
much better.. Thank you both!I'd like to note that while the two RFCs share some of the scope,
neither is a direct replacement of the other. I think Rowan previously
summarized it well in this email:
https://news-web.php.net/php.internals/129630.
As currently written, yes. However, as noted previously in the Context Manager thread we are open to allowing arbitrary values in the CM position, which would fall back to just using that value and then unsetting it. That would effectively replace the let syntax entirely with a unified syntax.
I have also voted No on this RFC, for many of the reasons already stated:
- The functionality is too limited.
- The functionality is inherently unreliable due to value escape.
- The syntax is far too non-standard and clumsy.
- Expanding CMs to fully encompass the behavior of this RFC is trivial, which would avoid redundant and confusing syntax.
--Larry Garfield
Hi
Am 2026-01-23 16:47, schrieb Larry Garfield:
As currently written, yes. However, as noted previously in the Context
Manager thread we are open to allowing arbitrary values in the CM
position, which would fall back to just using that value and then
unsetting it. That would effectively replace theletsyntax entirely
with a unified syntax.I have also voted No on this RFC, for many of the reasons already
stated:
- The functionality is too limited.
- The functionality is inherently unreliable due to value escape.
For these two I refer to the email I just sent in reply to Arnaud. I
believe that 4 example use cases are by no means an indication of an RFC
being limited in usefulness. Block scoping is a well-established feature
in programming languages and I'm positive that folks will be able to
come up with even more examples of where block scoping would have been
helpful to them to avoid bugs / make their code easier to reason about.
- The syntax is far too non-standard and clumsy.
My understanding the initial paragraph of your email is that the entire
functionality of the block scoping RFC could be included in the Context
Manager RFC. The Context Manager RFC uses the same "high-level" syntax
of having a dedicated block for declarations - just using using
instead of let as the keyword and using => instead of = for an
assignment (the latter of which was considered confusing in the
discussion). I'm sure I must be misunderstanding, because I don't follow
how the syntax of this RFC is "non-standard and clumsy" without this
equally applying to the context manager RFC. Can you rephrase?
- Expanding CMs to fully encompass the behavior of this RFC is trivial,
which would avoid redundant and confusing syntax.
The same is true the other way around, possible ideas are listed in the
Future Scope.
I'd also like to note that it was an explicit design goal of the block
scoping RFC to compose nicely with existing control structures to be
generically applicable. This enables several of the example use cases
listed in the RFC. The context manager RFC requires braces and a
proposed special case for try instead of just accepting any statement
like block scoping does. Due to its composibility, the block scoping RFC
is even compatible with future additions to the language (provided the
future additions follow the established syntax). As an example, pattern
matching comes to mind as another way of "writing into variables". Block
scoping will just work with match:
let ($x, $y) $result = match ($p) is {
Point(:$z, :$x, y: 4) => "x is $x, y is 4, z is $z",
};
to prevent $x and $y from leaking out of the match(). And similarly to
the foreach() future scope, we could allow match ($p) let is to
automatically block scope all variables bound by the pattern.
Best regards
Tim Düsterhus
My understanding the initial paragraph of your email is that the entire
functionality of the block scoping RFC could be included in the Context
Manager RFC. The Context Manager RFC uses the same "high-level" syntax
of having a dedicated block for declarations - just usingusing
instead ofletas the keyword and using=>instead of=for an
assignment (the latter of which was considered confusing in the
discussion). I'm sure I must be misunderstanding, because I don't follow
how the syntax of this RFC is "non-standard and clumsy" without this
equally applying to the context manager RFC. Can you rephrase?
Block scoping and CMs are related and overlap, but are different things.
let, in every language I am aware of that uses it, is an inline part of the variable declaration, and then they do something to resolve the "dead zone" question. Languages that have block scoping have had it from the beginning, so "variable dies at the next }" is built into the language semantics and development culture. Neither is true in PHP. So having a block-esque syntax for "only these special blocks and these special variables get block scoping" is something I have never seen before, and feels very clumsy.
CMs are about packaging up setup/teardown logic to make them reusable, and therefore more ergonomic. That setup/teardown can and often does include unsetting variables, but that's not its main purpose. It's just an implementation detail. In every language with such functionality, it is a block level construct.
Block scoping as presented here is essentially a "junior, limited CM", with a future scope of adding a Disposable interface to make it a less-limited CM. I fundamentally believe that is the wrong way around, and have already discussed elsewhere (I think) why forcing the context manager (packaged logic) and context variable (the variable(s) that will need cleanup) to be the same value is fundamentally limiting and flawed.
I proposed allowing the using syntax to handle non-CM objects specifically to incorporate the "degenerate case" where unsetting is the only meaningful teardown, and thereby avoid the need for a boilerplate new JustUnsetTheThing($thing) for the degenerate cases. CMs can also return $this from enterContext() if appropriate, which would then have the same effect as the Disposable interface.
So no matter how you slice it, having a separate CM from context variable provides more flexibility than the proposed let syntax, in a consistent and unified fashion. By tweaking CMs, we can allow it to also cover the simple, degenerate cases that block scoping handles in addition to the more robust options it naturally supports.
I'd also like to note that it was an explicit design goal of the block
scoping RFC to compose nicely with existing control structures to be
generically applicable. This enables several of the example use cases
listed in the RFC. The context manager RFC requires braces and a
proposed special case fortryinstead of just accepting any statement
like block scoping does. Due to its composibility, the block scoping RFC
is even compatible with future additions to the language (provided the
future additions follow the established syntax). As an example, pattern
matching comes to mind as another way of "writing into variables". Block
scoping will just work with match:let ($x, $y) $result = match ($p) is { Point(:$z, :$x, y: 4) => "x is $x, y is 4, z is $z", };to prevent $x and $y from leaking out of the
match(). And similarly to
theforeach()future scope, we could allowmatch ($p) let isto
automatically block scope all variables bound by the pattern.
thinking_face.gif
This is sort of what we were trying to noodle through with the questions about expression-oriented using, but it didn't stick. I would have to talk to Arnaud, but I suppose it's probably possible to allow using to work on an arbitrary construct and inherit its block. I'm quite open to discussing the feasibility of that.
It's really unfortunate that both proposals were worked on separately, as I do believe there are good ideas in both. But I would much rather work from the more-flexible design and then short-cut the degenerate cases, as that gives, I believe, a better outcome in the end.
--Larry Garfield
I'd like to note that while the two RFCs share some of the scope,
neither is a direct replacement of the other. I think Rowan previously
summarized it well in this email:
https://news-web.php.net/php.internals/129630.The focus of the “let construct (Block Scoping)” RFC is enabling block
scoping - as the name implies. The examples in the “Examples” section of
the RFC are intended to reflect some real-world situations where either
Seifeddine or I would've liked to have block scoping. Except for the
“process_file()” example, I don't believe the Context Manager RFC (as
currently proposed) would be a suitable replacement.Best regards
Tim Düsterhus
My apologies for the confusion. Thank you for the clarification, Tim. I retract my previous statement.
Hey Tim,
I went for "abstain".
I'm a proponent of functional programming paradigms, and I frequently touch
Haskell / Nix, which have let ... in ... and ... where ... , which are
nice.
I feel like cluttering the PHP language for something that is already (in
my own opinion) resolved by IIFEs (and inlining/optimization thereof) is
not necessary.
I don't mind if the feature makes it into the language, but I feel like it
just complicates the AST further, for very marginal gains.
Greets,
Marco Pivetta
https://mastodon.social/@ocramius
Hi
we just opened the vote on the “let construct (Block Scoping)” RFC
(which was originally proposed as “use construct”, but the keyword
changed as a result of the discussion).Please find the following resources:
- RFC: https://wiki.php.net/rfc/optin_block_scoping
- Official Discussion Thread:
https://news-web.php.net/php.internals/129059- Related Discussion Thread:
https://news-web.php.net/php.internals/129251There is one primary vote to cast on the RFC. Voting will run for 2
weeks until 2026-02-05 09:30 UTC.Best regards
Tim Düsterhus
Hey Marco,
Hey Tim,
I went for "abstain".
I'm a proponent of functional programming paradigms, and I frequently
touch Haskell / Nix, which havelet ... in ...and... where ...,
which are nice.I feel like cluttering the PHP language for something that is already
(in my own opinion) resolved by IIFEs (and inlining/optimization
thereof) is not necessary.I don't mind if the feature makes it into the language, but I feel
like it just complicates the AST further, for very marginal gains.Greets,
Marco Pivetta
That's pretty much the sentiment I share. It's additional complexity for
the language, with a benefit not worth it.
I definitely prefer this over context managers (though they don't solve
exactly the same goals, there's quite a bit of overlap).
But for me I'd like to see neither.
As to the more specific semantics of the RFC:
It's not natural to write code this way (especially if there are
multiple such objects created across a function - you don't want to nest
5 times, for 5 objects), and there are only very few instances where it
actually matters when exactly a value is destroyed.
While the examples certainly correctly show usages where it's useful, an
explicit unset(); just solves this as well in most cases. However a
let() is much more implicit than the actual unset() telling me "I NEED
this to be cleared here". It also doesn't prevent me from outliving the
value.
It feels like let is supposed to be clearing the object. However, with
your example for process_file() it's fine. However if you have
zend.exception_ignore_args=0 (as you should if you disable displaying
errors) and forward the $file object as an arg (e.g. read_all($file)),
the $file object will be attached to the exception (being an arg). It
will not, as one may expect, be actually freed when the exception is thrown.
That's subtle, and let() isn't the holy grail for solving these things.
It creates false expectations in sufficiently complex code.
The main remaining utility I see in let() is highlighting intentions,
rather than being actually useful in the language. Which goes back to
the first point of "additional complexity, but not worth it".
Thanks,
Bob
Le 22/01/2026 à 10:12, Tim Düsterhus a écrit :
Hi
we just opened the vote on the “let construct (Block Scoping)” RFC
(which was originally proposed as “use construct”, but the keyword
changed as a result of the discussion).Please find the following resources:
- RFC: https://wiki.php.net/rfc/optin_block_scoping
- Official Discussion Thread:
https://news-web.php.net/php.internals/129059- Related Discussion Thread:
https://news-web.php.net/php.internals/129251
Hello,
I personally can't vote, but I'd like very much this feature to happen.
I have no strong opinion about the syntax (let is fine for me, as would
be with, using, or anything else...).
Just wanted to add my 2cents here, thank you all contribs to the time
you give to PHP.
--
Pierre