Time-based QR codes: how scheduled redirects work

A dynamic QR code that changes destination is nothing new; agencies use that trick constantly to swap a landing page without reprinting a poster. A time-based QR code goes a step further: it changes automatically, on a schedule, with no one touching the dashboard. Point a phone at the same printed code at 8am and you land on the breakfast menu. Scan it at 7pm and you land on the dinner menu, or a happy-hour offer, or a "we're closed, here's tomorrow's booking link" page. The code never moves. The rule engine behind it does the work.

This is a genuinely useful feature for campaigns that already have a built-in rhythm: restaurants with dayparted menus, retail promotions that only make sense during trading hours, events where the pre-show, day-of, and post-show experience should each get a different landing page. It is also one of the more misunderstood dynamic QR features, because the two questions everyone asks first, whose clock governs the schedule and what happens to someone outside the window, rarely get a straight answer. This piece works through both, plus the caching problem that makes a correctly configured schedule look broken.

How a time-based QR code actually works

A time-based (sometimes called "smart" or "scheduled") QR code is built on the same foundation as any dynamic QR code: the printed code encodes a short, permanent redirect URL, and the destination it points to is looked up on the server at the moment of the scan, not baked into the code itself. See the difference between that model and a static QR code if you need the fundamentals first.

Time-based rules add a scheduling layer on top of that lookup. Instead of one fixed destination, the platform holds a small ordered list of time windows, each mapped to a destination, plus one fallback destination for anything outside those windows. When a scan comes in, the server checks the current time against the configured windows and returns whichever URL matches. Across the smart-QR implementations from vendors like Uniqode, QR Code Chimp, and Beaconstac, this evaluation happens server-side at scan time, not by shipping a script to the visitor's browser that decides client-side. That distinction matters for one practical reason: a server-side decision is instant and works identically on every device and browser, while a client-side redirect depends on JavaScript actually running before the user sees anything, which is slower and less reliable on a flaky mobile connection.

The fallback destination is not optional in any implementation worth using. Every scan that lands outside every configured window needs somewhere to go, and "nowhere" is a broken code. A sensible default is a general landing page, a "see today's hours" message, or simply the same content that would apply during the nearest active window. Rule counts are vendor-specific (Uniqode, for example, caps a single code at eleven smart rules), so if a schedule needs more than a handful of distinct windows, check the limit before designing the campaign around it.

Setting up a recurring schedule

Most real campaigns don't need a one-off time window; they need a recurring one. The standard pattern is a repeating weekly schedule: pick the days (Monday to Friday, or just Saturday and Sunday, or every day), then set a start and end time for each window. A restaurant might configure three recurring windows on the same code: 07:00 to 11:00 for breakfast, 11:00 to 16:00 for lunch, and 16:00 to 22:00 for dinner, each pointing at its own menu page. That's the exact use case covered in more depth in the restaurant menu QR guide, and it's worth reading alongside this one if food service is the campaign.

A bar running a Friday happy hour would set a single narrower recurring window, say Friday 17:00 to 19:00, pointing at the promotion page, with the fallback pointing at the regular drinks menu the rest of the week. The mechanism is identical either way: more windows just means more rules to maintain, and every rule needs a destination that's actually ready before the window opens. A scheduled rule firing at 17:00 to a page that only goes live at 17:05 defeats the point.

Which clock governs the schedule: yours or the scanner's?

This is the question that trips up almost every explanation of time-based QR codes, because the honest answer is: it depends on the platform, and it is not fixed by any standard. Nothing in the QR code specification or in HTTP dictates which clock a scheduled redirect should use. In practice, the smart-QR implementations reviewed for this piece (Uniqode, QR Code Chimp, QR Planet) all bind each schedule to a single configured timezone chosen when the rule is set up, typically the venue's or campaign's timezone, not the timezone of whichever device happens to scan the code. That's the only design that makes sense for a physical location: a restaurant in Amsterdam wants its lunch window to start at 11:00 Amsterdam time regardless of whether the person scanning is a local or a tourist whose phone is still set to their home timezone.

It's worth keeping two separate things apart here, because vendor documentation sometimes blurs them. Which destination a schedule serves is governed by the venue's configured timezone. How a scan's timestamp gets localised in your analytics dashboard afterwards is a different mechanism, often derived from the scanning device's IP address or reported location, and it can legitimately show a different local time than the one that decided the redirect. If a report shows a scan logged at an odd hour relative to the schedule, that's usually the analytics localisation, not the scheduling rule, doing something unexpected.

For a multi-location client (a chain with stores in New York and London), a single time-based rule template doesn't automatically travel across timezones. Each location's code needs its own timezone setting so that "open at 9am" means 9am locally in each market, not 9am in whichever timezone the rule was first created in.

Why the schedule looks like it "didn't update": redirect type and caching

A correctly configured time-based rule can still look broken to a specific returning visitor, and the cause is almost always caching, not the rule engine. This is worth understanding at the HTTP level because it changes how the redirect itself should be built.

HTTP defines two commonly used redirect status codes with materially different caching defaults. A 301 Moved Permanently response is, per RFC 9110, heuristically cacheable by default, meaning a browser is allowed to remember it and skip asking the server again on a later visit. A 302 Found (and its stricter cousin 307 Temporary Redirect) is not cacheable by default; the browser is expected to check with the server every time unless the response explicitly says otherwise with cache-control headers. That's a hard distinction from the HTTP specification, not a vendor quirk.

The practical consequence for scheduled content is direct: any redirect whose destination is meant to change on a timer should use a 302/307-style response, never a 301. If a code was ever built or briefly configured as a permanent redirect, some browsers will cache that first destination locally and keep serving it from cache on repeat visits, ignoring the fact that the server-side rule has since moved on to a different window. This is a genuinely easy mistake to make once, and a genuinely annoying one to debug, because the code works correctly for every new visitor and appears "stuck" only for people who scanned it before.

Caching can also happen a layer below the browser. Public WiFi captive portals, carrier-level proxies, and a device's own DNS cache can each hold onto an earlier response independently of what the origin server is doing, which is one reason a schedule that tests perfectly on a home connection can behave inconsistently on a venue's guest WiFi. None of this is something a QR platform can fully control; it's a reason to test a live schedule from more than one network before trusting it for a print run, and it's also why redirect speed is worth understanding on its own, since the same redirect chain that determines caching behaviour also determines how fast the scan resolves.

What happens outside the scheduled window

Every window-based schedule needs an explicit answer for "outside all of the above," and the answer is the fallback destination set when the rules were configured, not a dead link or an error page by default. What that fallback should actually be is a content decision, not a technical one: a restaurant might route off-hours scans to a page with opening times and a booking link; an event might route pre-doors scans to a countdown or a schedule page and post-event scans to a highlights recap or next-event signup. The point of setting this deliberately is that a QR code printed once and left in the field, on a sign, a flyer, a vehicle wrap, will get scanned at every hour of the day whether or not the campaign is "live" at that moment, and every one of those scans is a person who took the action you asked for.

Daylight saving time and other edge cases

Scheduling by clock time runs into a genuine technical edge case twice a year in regions that observe daylight saving time. The IANA time zone database (sometimes called the Olson database), the reference dataset that most software uses to resolve timezone offsets, documents that a spring-forward transition creates a local time that never occurs (for example, 02:00 to 03:00 simply doesn't happen on the day clocks jump forward), while a fall-back transition creates an hour that occurs twice. A schedule window boundary that happens to land inside either of those transitions is an edge case that's well documented in timezone-aware software generally, though no smart-QR vendor's documentation spells out exactly how their own rule engine handles it. The safe approach is pragmatic rather than clever: avoid setting a window boundary in the small hours around a known DST transition date, and check any schedule that straddles one manually the first time it happens, rather than assuming the platform has silently handled it correctly.

Is a time-based schedule more privacy-friendly than a geotargeted one?

It's a fair question, since geotargeted QR codes solve a similar-sounding problem (serve a different destination depending on context) using a different variable. The two are not equivalent under data protection law. A geotargeted rule needs to know where the scanning device is, which means processing location data, and location data tied to an individual is personal data under the GDPR, triggering the usual requirements around lawful basis and, typically, consent. A time-based rule needs none of that. The only input is the server's own clock; nothing about the scanning device, its location, or its user is read or stored to decide which destination to serve. That makes time-based scheduling the simpler option from a privacy standpoint whenever the campaign's logic can be expressed in time rather than location, which is more often than agencies assume: a lunch menu doesn't need to know where you are, only what time it is. For campaigns that genuinely also need consent-driven personal data handling elsewhere, see the broader rundown in are QR codes GDPR-compliant.

Where agencies actually use this

Hospitality dayparting. The clearest use case: one printed table-tent or window sticker, three or four menus across the day, no reprinting when the kitchen changes what it serves. Covered in full in the restaurant menu QR guide.

Time-limited retail promotions. A happy hour, a lunchtime-only discount, a weekend-only sale: the code can carry the promotion automatically during the window and revert to standard pricing or the regular catalogue the rest of the time, without a staff member remembering to swap anything.

Event lifecycle content. The same printed badge, lanyard, or signage can point at a pre-event schedule before doors open, a live agenda or wayfinding page during the event, and a thank-you or recap page afterwards, which is worth planning alongside the broader events and trade shows playbook.

On-screen and digital signage. A QR code shown on a looping video or a TV screen already has to account for how long a viewer has to scan it; layering a time schedule on top lets the same on-screen code serve different content for a morning slot versus an evening slot, which pairs with the guidance in the on-screen and TV QR post.

Out-of-hours signage. Anything printed and left in public (a shopfront sticker, a vehicle wrap, an outdoor sign) gets scanned at every hour whether the business is open or not; a fallback destination that acknowledges that (hours, contact, next opening) turns an off-hours scan into a useful interaction instead of a dead end.

Frequently asked questions

Can a QR code change based on time of day?

Yes. A dynamic QR code's destination is resolved on the server at scan time, so a platform can hold multiple destinations against one code and switch between them based on a configured schedule, with no change to the printed code itself.

Which timezone does a scheduled QR code use, the scanner's phone or the venue's?

In the smart-QR implementations reviewed here, each rule is bound to a timezone chosen when the schedule is configured, typically the venue's or campaign's own timezone, not the timezone of whichever device happens to scan the code. This is a vendor design choice, not something mandated by the QR standard or by HTTP.

Should a time-based QR redirect use a 301 or a 302?

Use a 302 (or 307) style redirect, not a 301. Per RFC 9110, a 301 is heuristically cacheable by default, so a browser can remember and reuse the first destination it saw, which will make a later scheduled change appear not to apply for that visitor. A 302/307 is not cached by default, so the browser checks with the server on every scan.

What happens if someone scans a scheduled QR code outside its active window?

They're sent to the fallback (default) destination configured when the schedule was set up. Every window-based schedule needs one; without it, an out-of-window scan has nowhere defined to go.

Can you set a recurring weekly schedule instead of a single one-off window?

Yes, this is the standard pattern for real campaigns. Choose the days it applies to (a subset of the week or every day) and a start and end time, and the platform re-evaluates that window every time it recurs, with no need to reconfigure it each week.

Does daylight saving time break a scheduled QR code?

It can create an edge case around the two DST transition dates each year: spring-forward skips an hour that never occurs locally, and fall-back repeats an hour. A window boundary landing inside either transition is worth checking manually the first time it happens, since vendor documentation rarely spells out exactly how their scheduler resolves it.

Is time-based QR scheduling GDPR-compliant?

It doesn't raise the same questions a geotargeted code does. A time-based rule only reads the server's clock, no personal or location data about the scanning device is processed to pick a destination, so it sits outside the data-protection considerations that apply to location-based personalisation.

Can a QR code be set to show "closed" outside business hours?

Yes, that's simply the fallback destination doing its job: instead of routing off-hours scans to a menu or promotion page, point the fallback at an hours/contact page or a "we'll be back at [time]" message.

How is this different from a geotargeted QR code?

Both serve a different destination from the same printed code, but on different inputs. A geotargeted rule reads the scanning device's location; a time-based rule reads the server's clock. They can be combined (a schedule that only applies at one location) but they solve different problems and carry different privacy implications.

The short version

A time-based QR code is a dynamic code with a scheduling layer on top: the server checks the current time against a set of configured windows and returns whichever destination matches, with a fallback for anything outside them. The schedule runs on a timezone chosen when it's configured, not the scanner's device clock, so multi-location campaigns need a timezone set per location, not one rule copied everywhere. Build the redirect as a 302/307, not a 301, or a browser's own caching will make a correctly updated schedule look stuck for returning visitors. Set a real fallback destination, check any window boundary that lands near a daylight saving transition, and test the live code from more than one network before it goes to print. Done properly, it's one of the few QR features that removes work from a campaign instead of adding it: the menu, the promotion, or the signage changes itself, on time, without anyone touching a dashboard.