Time in Force: Four MetaTrader Order Lifetimes, Not Three

Every pending order you place in MetaTrader 5 carries a setting that decides how long it stays alive. The order window calls it Expiration. Most published guides call it time in force and present it as a single menu of five or six choices.

That menu does not exist. What sits in the platform is two separate order properties, filled in from two separate controls, answering two questions that have nothing to do with each other. One decides how long the order waits. The other decides what happens at the instant it is filled.

The specification behind those two fields is public, and it settles several things the guides state without a source. It also contains a fourth expiration mode that the equity-broker menus have no equivalent for, and one condition under which choosing Good Till Canceled does not keep your order alive overnight at all.

Two Separate Fields, and Every Guide Merges Them

Open the order window for a pending order in MetaTrader 5 and two dropdowns sit near the bottom. One is labelled Expiration. The other is labelled Fill policy, and it offers Fill or Kill, Immediate or Cancel and Return.

They are stored as two different order properties. The platform names one of them the order lifetime and the other the order filling type, and a trade request carries both. Nothing about the value in one constrains the value in the other.

The published guides put all of them in one list. A page will introduce time in force, then run Day, Good Till Canceled and Good Till Date straight into Fill or Kill and Immediate or Cancel as though a single dropdown produced all five. One of the pages that does this then asks, in its own frequently-asked section, how Fill or Kill differs from Immediate or Cancel, which is a question about the other field entirely.

The distinction is not pedantic, because the two fields fail in different ways. A lifetime setting decides how long an unfilled order waits for its price. A fill policy decides what the server does at the moment a price arrives and the available volume is smaller than the volume you asked for. The field that decides how a fill may be split is where partial execution is settled, and it has no bearing on whether your order is still there tomorrow.

Reading a list that mixes them, a trader can pick Fill or Kill believing it is a duration, and receive an order that either fills completely on the spot or ceases to exist.

The Four Lifetimes MetaTrader 5 Documents

The lifetime property takes four values. Three of them map onto vocabulary an equities trader recognises. The fourth does not.

The first keeps the order queued until somebody removes it. The second limits it to the current trading day. The third holds it until an exact moment you nominate, date and time together. The fourth is set against a day rather than a moment, and it is discussed in the next section.

The order window labels the first three Good Till Canceled, Today and Specified, with a separate Expiration date field carrying the fourth. The programming interface names them GTC, DAY, SPECIFIED and SPECIFIED_DAY.

So the label you see and the constant recorded against your order are not the same string. That matters when you read a rejection in the journal or inspect an order property in a script, because the log speaks the second vocabulary and the window speaks the first.

The distinction between the third and fourth values is easy to lose. One expires at a moment. The other expires with reference to a day. They are separate settings with separate constants, and the difference shows up in exactly the situation described below. The pending order types themselves are chosen independently of all four.

The Fourth Mode Has No Equity Equivalent

Good Till Date, in the equity platforms the comparable guides describe, is one thing: an order that dies at a date you choose. MetaTrader splits that idea in two, and keeps both.

Nominating an exact expiry moment is one setting. Nominating a day and letting the platform decide the moment within it is another. The second carries a behaviour the first does not have: if the moment the rule produces falls outside a trading session, the expiry is not applied at that moment. It is deferred to the next point at which the symbol is trading.

That behaviour is the reason the mode exists. An order set against a day on an instrument that stops trading at the weekend does not quietly lapse into a closed market. It survives until the market is open again and expires there, which is a different outcome from an exact timestamp that passes while nothing is trading.

One wrinkle is worth stating plainly, because it comes from MetaQuotes rather than from any third party. The programming reference puts the end of this mode at 23:59:59 of the nominated day. The terminal help puts the same field at 00:00 of that day.

Both documents agree on the out-of-session deferral and disagree on the boundary, and neither of them is a competitor blog. Treat the exact second as undetermined, and pick the day so that a twenty-four hour ambiguity at either end cannot decide the trade.

Choosing GTC Does Not Mean Your Stops Survive the Night

This is the finding that changes what a reader does, and none of the readable comparisons contains it.

Good Till Canceled reads as a promise: the order waits until you remove it. In MetaTrader that promise is conditional on a second setting, and the second setting lives on the symbol rather than on your order.

The platform defines a mode that applies specifically when a symbol runs on GTC expiry. It has three possible values. Under the first, pending orders and the Stop Loss and Take Profit levels attached to positions all persist indefinitely until they are cancelled, which is what most traders assume GTC means everywhere.

Under the second, they do not. Orders are treated as valid for one trading day, and when that day ends the platform removes pending orders and clears every Stop Loss and Take Profit level along with them. A trader who selected Good Till Canceled, went to bed, and expected a protective stop to be sitting on an open position in the morning would find the position unprotected.

The third value splits the difference. Pending orders go when the trading day rolls over, and the protective levels sitting on open positions stay where you put them.

Three symbols on one account can each carry a different one of these. The choice is the broker’s, it is recorded per symbol, and the order window does not surface it while you are placing the order. The practical decision this creates for a trader who works in one pass a day, and the trade-off between leaving an order overnight and re-placing it each session, belongs to leaving one order open per day rather than to this page.

Your Symbol Decides Which Lifetimes You May Pick

The four lifetimes are what the platform supports. They are not necessarily what your symbol offers.

Permission is held as a flags field on the symbol, listing which expiration modes are allowed. Four flags exist, one for each lifetime, and a symbol carries whichever combination the broker configured. A mode whose flag is absent is not available on that instrument, however clearly the platform documents it.

The architecture will look familiar to anyone who has read the fill policy rules, because it is the same architecture. Allowed fill policies are held as a flags field on the symbol too. Two parallel permission lists, two independent order properties, both set by the broker per instrument and neither of them a preference you own.

This is where a rejected order usually comes from when the request looked reasonable. Submitting a lifetime the symbol does not permit is not a market condition or a pricing problem. It is a request the server cannot accept, and it fails on the property rather than on the price. The same per-symbol logic governs how close to the current price an order may sit, which is a separate constraint that produces a similarly opaque rejection.

The 30-to-90-Day Claim, and What the Specification Actually Says

A figure travels through the published guides on this topic: brokers cancel Good Till Canceled orders automatically after some period, typically given as 30, 60 or 90 days.

One of the comparisons read for this page states it in that exact form. None of them attributes it to a broker, an exchange rule, a regulator or a platform specification. It is presented as general knowledge about how the industry behaves.

It appears nowhere in the MetaQuotes documentation. There is no day count in the expiration constants, none in the symbol permission flags, and none in the GTC mode described above. The specification contains no automatic cancellation window of any length.

What it does contain is the mechanism that ends a GTC order without you: the per-symbol GTC mode, which either preserves the order indefinitely or clears it when the trading day turns over. That is a rule about days rather than months, and it is documented.

Because no official source states a 30, 60 or 90 day window, no such figure appears anywhere on this page. If your broker applies one, it is that broker’s own arrangement, and the place to read it is the contract specification for the instrument rather than a general article about order types.

The Expiration Stamp Is Written in Server Time

An expiry you nominate is stored against the order as a timestamp. The clock that timestamp belongs to is not yours.

MetaTrader records order and position times against the time zone of the trading server, and the platform states that dependency directly. A trader in one region setting an expiry for the end of a Friday is setting it against a server clock that may already have moved into Saturday, or may still be several hours behind.

The gap is rarely large enough to notice on a week-long order and easily large enough to matter on a one-day one. An order set to expire at the close of a session can expire a session early or a session late purely because the two clocks disagree, and nothing in the order window flags the difference.

The offset is a property of the broker rather than of the platform, so it is read once per account and then remembered. The clock your broker stamps orders with covers how to establish that offset and where it shows up elsewhere.

Checking Your Own Symbol Before You Rely on an Overnight Order

Four checks, each answerable inside the platform, settle whether an order you leave will behave the way you expect.

1. Open the order window on the instrument you trade and read the Expiration list. Whichever of the four modes is missing is a mode the broker has not permitted on that symbol.
2. Confirm that the Fill policy control is a separate dropdown from the Expiration one, so that Fill or Kill is never mistaken for a duration.
3. Establish whether the symbol keeps Stop Loss and Take Profit levels across the day boundary. The specification for the instrument is where a broker states this, and it decides whether an overnight stop is protection or an assumption.
4. Compare the server clock against your own before setting any expiry shorter than a week, and set the expiry against the server figure.