Timeframes, Ticks and How Bars Are Built

The previous lesson showed that a bar discards information. This one shows where the discarding happens, how much of it is a choice you make, and why one of those choices — the base time interval of a database — is far harder to reverse than it looks in the dialog box.

The raw material: trade prints

Underneath every chart is a stream of individual trades. Each one carries a timestamp, a price, a size, and usually an exchange identifier and one or more condition codes saying what kind of trade it was: a regular sale, an auction print, an odd lot, a trade reported late, a trade agreed away from the exchange.

Those condition codes matter more than beginners expect. Whether a particular print is allowed to set the day’s high, or to count toward volume, or to be the official close, is a decision made by whoever built your data — and different vendors make it differently. This is one reason two feeds can show different highs for the same session and both be defensible.

From trade to chart

each step discards something

1. Trades at the exchangeTimestamp, price, size, condition codescomplete
2. Vendor’s tick streamFiltered and normalised by vendor rulesfirst losses
3. Base-interval bars in your databaseThe finest grain you will ever have
4. Compressed bars5-minute, hourly, daily, weekly — built on demandfurther losses
5. Indicators and rulesEverything you compute sits on top of all of it

Time-based bars: buckets on a clock

The ordinary way to turn prints into bars is to divide the clock into equal buckets and summarise each one. A five-minute bar covers a five-minute slot; every print with a timestamp inside that slot contributes.

Two mechanical details of that bucketing decide whether your intraday analysis lines up with anyone else’s.

Which timestamp the bar wears

A bar covering 09:00:00 to 09:29:59 could reasonably be labelled 09:00, or 09:29:59, or with the time of the first trade in it, or the time of the last. AmiBroker treats this as a preference rather than a law: Tools → Preferences → Intraday offers exactly those four options for “Time compressed bars show” — time of the first tick inside the bar, time of the last tick inside the bar, start time of the interval, or end time of the interval.

The setting changes no prices at all. It changes which label each set of prices is filed under, which is enough to shift every one of your intraday comparisons by one bar if you and your data source disagree about it.

Where the buckets start

By default, minute buckets are anchored to the clock, so a 45-minute interval on a market that opens at 09:30 produces bars beginning at 09:00, 09:45, 10:30 and so on — with the first bar of the session truncated. The same Preferences page offers Align custom minute bars to regular market hours, which trims the pre-market portion so that a new bar begins exactly when trading hours start: 09:30, 10:15, 11:00.

Neither behaviour is wrong. But an “opening range” measured on clock-anchored bars is a different quantity from one measured on session-anchored bars, and nothing in the chart tells you which you are looking at.

Compression: building a bigger bar from smaller ones

Once bars exist at some interval, larger intervals are produced by compressing them. The rule is the same one used to build a bar from trades, applied one level up: the open of the compressed bar is the open of the first sub-bar, the close is the close of the last, the high and low are the extremes, and volume is the sum.

AmiBroker names these rules explicitly in its timeframe functions — compressOpen, compressHigh, compressLow, compressLast and compressVolume are the documented modes of TimeFrameCompress(). Seeing them written down is useful, because it makes clear that compression is arithmetic, not interpretation.

Five 1-minute bars compressed into one 5-minute bar (synthetic)

Open comes from the first sub-bar, close from the last, high and low from the extremes, volume from the sum. Everything else is gone.

Bar	09:30	09:31	09:32	09:33	09:34	→ 09:30 (5-min)
Open	50.10	50.22	50.31	50.18	50.25	50.10
High	50.28	50.35	50.33	50.27	50.44	50.44
Low	50.08	50.19	50.14	50.12	50.21	50.08
Close	50.22	50.31	50.18	50.25	50.41	50.41
Volume	12,400	8,900	15,200	7,600	21,300	65,400

Open comes from the first sub-bar, close from the last, high and low from the extremes, volume from the sum. Everything else is gone. Prices in this diagram are invented for the illustration. They are not market data and nothing should be inferred from them.

Look at what the compressed bar cannot say. Three of the five minutes closed lower than they opened; the five-minute bar shows a clean advance. The 09:32 minute made a lower low than 09:31 after making a lower high — a small structural event, entirely invisible one level up. Every compression step erases structure at the level below it.

!Important

Compression only runs one way. From one-minute bars you can build any interval of two minutes or more; from fifteen-minute bars you can never recover one-minute bars; from end-of-day data you can never obtain intraday data at all. The official guide states this plainly, and it is the single most consequential fact in this lesson.

Daily bars are not a special case

It is tempting to think of daily data as the natural unit and intraday as a subdivision of it. Mechanically, it is the other way round: a daily bar is just another compression, and its boundaries have to be defined by someone.

In AmiBroker those definitions live in File → Database Settings → Intraday settings, and they are per-database. Two of them change what a daily bar contains:

• Filtering decides which intraday data is displayed at all: 24 hours with no filtering, day session only, night session only, or day and night sessions only. Trading hours for each session are entered in your local time zone, with a separate time-shift value for the difference between your clock and the exchange’s.
• Daily time-compression uses decides which clock defines a day when intraday bars are compressed to daily: exchange time, local time, or the day and night session times as defined above.

Change either and the daily bars change, from the same underlying prints. A rule that triggers on the daily close is therefore sensitive to a setting most users never open.

⌀Data quality warning

Filtering hides data; it does not delete it. If bars vanish from a chart but are still present in the Quote Editor — which always shows every bar, regardless of filtering — the Intraday Settings filter is the reason. Chasing that as a “missing data” problem is a common and expensive detour.

Sessions, exchange time and daylight saving get a whole part of their own later in the course. For now, treat “what counts as a day” as a configured answer rather than an obvious one.

The intervals AmiBroker offers

The built-in chart intervals are daily, weekly, monthly, hourly, 15-minute, 5-minute and 1-minute, plus 15-second, 5-second and tick for real-time intraday work. On top of those you can define five custom N-minute intervals and five custom N-tick intervals in Tools → Preferences → Intraday; custom intervals appear only in the View → Intraday menu.

N-tick bars are worth a moment because they are the clearest example of a bar that is not a clock bucket at all. A 133-tick bar closes after 133 prints, whenever that happens to be — fast in a busy minute, slow in a quiet hour. It equalises activity instead of time. AFL can address them with TimeFrameSet() given a negative interval, and the guide is explicit that this works only if the database’s base time interval is tick.

✱AmiBroker Professional required

Tick and second-based intervals require a real-time data source, and real-time data requires the Professional edition. Everything else in this lesson — daily, weekly, monthly, and any intraday interval already present in an imported historical file — works in the Standard edition. The Level A path through this course never needs tick data.

The base time interval: the decision you make once

Every AmiBroker database has a base time interval, set in File → Database Settings. It defines the finest grain the database stores. Everything coarser is produced by compression on the fly; nothing finer is ever available.

Three consequences follow directly:

1. An end-of-day database can never show intraday charts. The guide says so from both directions: intraday charting and analysis are unavailable until the base interval is set below end-of-day, and on the charting side, intraday intervals are disabled when the database is in end-of-day mode.
2. The base interval sets a floor, and every interval at or above it becomes available. Set it to 5-minute and all periodicities from 5-minute up are enabled. Set it to 1-minute and you additionally get 1-minute, at a cost described below.
3. Changing the setting later does not give you finer history. This is the part that catches people, so it is worth being precise about what the documentation does and does not say.

✕Common mistake

The claim you will read in forums is that the base interval control is greyed out after database creation. The official documentation does not say that. What it says is that for real-time sources the base interval “should be set once at the database creation time”, because a real-time source collects ticks and packs them into bars of that grain.

The reason the decision is effectively permanent is physical rather than a matter of the user interface: bars that have already been compressed and stored at a coarse grain cannot be un-compressed. Changing the setting afterwards does not retroactively refine the history you already hold. To get finer data you create a new database with the finer base interval and collect or import the history again.

The guide’s own recommended workaround for wanting both long daily histories and intraday detail is to run two databases — one end-of-day, one intraday — and, where the data plugin supports it, the Allow mixed EOD/Intraday data option, which lets a single database hold both kinds of bar.

Why not simply store everything at tick resolution?

Because bars cost memory, and the arithmetic is unforgiving. AmiBroker’s performance documentation states that one data bar occupies 40 bytes. A hundred thousand bars is therefore about 4 MB per symbol, actually allocated, and the guide advises against going beyond roughly 100,000 bars per symbol when working with a 4 MB CPU cache. The Database Settings dialog shows the equivalent number of days next to the bar count for your chosen interval, which is the number worth reading before you accept a value.

A 500-symbol universe at 100,000 one-minute bars each is not a configuration problem; it is a machine specification. The base-interval choice is therefore a genuine trade-off between history, granularity and hardware — which is exactly why it deserves to be made deliberately rather than by accepting a default.

A decision procedure

Ask, in this order:

1. What is the shortest holding period I want to be able to study? If the answer is days or longer, an end-of-day database is not a compromise — it is the right tool, and it will hold decades of history on any machine.
2. Do I need to see inside the day at all? If yes, what is the coarsest intraday interval that would answer the question? Choose that as the base interval, not the finest one available.
3. How much history do I need at that grain, and can I afford it? Multiply bars per symbol by symbols by 40 bytes and look at the result before committing.
4. Am I willing to rebuild if I am wrong? If not, err one step finer than you think you need — but only one, and only if the memory arithmetic allows it.

Part 19 walks through this again with an intraday database in front of you. Deciding it now is cheaper than deciding it in six months with a database full of data.

Recap

Bars are built by bucketing trades, and every level of bucketing throws away the structure below it. The timestamp a bar carries and the point at which buckets start are configurable and worth checking. Daily bars are compressions like any other, and what counts as a day is defined by per-database session settings. Compression runs in one direction only, which makes the base time interval of a database a decision that is expensive to revisit — not because a control is locked, but because the information was never stored.

The next lesson takes a different kind of loss: not detail discarded by compression, but prices deliberately rewritten by corporate actions.

Check your understanding

Question 1. Your database has a base time interval of 15-minute. Which of these can you chart?

• 1-minute, because AmiBroker can subdivide bars
• 5-minute, because it divides evenly into 15
• Hourly, daily and weekly, but nothing below 15-minute
• Any interval, since periodicity is only a display setting

Show the answer and why

Answer: Hourly, daily and weekly, but nothing below 15-minute

The base interval is a floor. Every interval at or above it is available by compression; nothing below it can be produced, because the finer bars were never stored.

Question 2. A five-minute bar is built from five one-minute bars. Three of the five closed below their open, yet the five-minute bar closed well above its open. Is that a data error?

• True — the bars are inconsistent
• False — this is normal compression

Show the answer and why

Answer: False — this is normal compression

The compressed close comes from the last sub-bar only, and the compressed open from the first. What happened in between does not enter the compressed bar at all. Losing that structure is what compression is.

Question 3. Two people run the same opening-range formula on the same instrument and get different answers. Which of these could explain it? Select all that apply.

• One has bars timestamped at the start of the interval, the other at the end
• One has "Align custom minute bars to regular market hours" enabled
• Their Intraday Settings filter different sessions
• One is using a faster computer

Show the answer and why

Answer: One has bars timestamped at the start of the interval, the other at the end, One has "Align custom minute bars to regular market hours" enabled, Their Intraday Settings filter different sessions

All three of the first options change which prints land in which bar, or which label a bar carries. Processing speed changes how long the calculation takes, not what it contains.

Question 4. You created an end-of-day database two years ago and now want one-minute charts of that history. What is the honest answer?

• Change the base time interval and refresh the database
• Use TimeFrameSet( in1Minute ) to subdivide the daily bars
• The one-minute history was never stored, so it must be obtained again into a new database
• Enable Allow mixed EOD/Intraday data and the minute bars will appear

Show the answer and why

Answer: The one-minute history was never stored, so it must be obtained again into a new database

Compression is one-directional. Neither a setting nor an AFL function can manufacture detail that was discarded before storage. The mixed EOD/Intraday option lets one database hold both kinds of bar going forward; it does not create past minute bars.

Check my answersClear