Tableau Quiz: Date Functions
9 questions · exam conditions
0:00
Date FunctionsQuestion 1 of 9

For each transaction date, an analyst needs a calculated date representing the final calendar day of that transaction's quarter.

Which calculation correctly returns the last day of the quarter containing [Transaction Date]?

DATEADD('day', -1, DATETRUNC('quarter', [Transaction Date]))
DATEADD('day', -1, DATEADD('quarter', 1, DATETRUNC('quarter', [Transaction Date])))
DATEADD('quarter', 1, DATEADD('day', -1, DATETRUNC('quarter', [Transaction Date])))
DATEADD('month', 3, DATETRUNC('quarter', [Transaction Date]))
← Back to quizzes

Tableau Quiz

Tableau Quiz: Date Functions

Practice Date Functions in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Date Functions, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

For each transaction date, an analyst needs a calculated date representing the final calendar day of that transaction's quarter.

Which calculation correctly returns the last day of the quarter containing [Transaction Date]?

  1. DATEADD('day', -1, DATETRUNC('quarter', [Transaction Date]))
  2. DATEADD('day', -1, DATEADD('quarter', 1, DATETRUNC('quarter', [Transaction Date]))) (correct answer)
  3. DATEADD('quarter', 1, DATEADD('day', -1, DATETRUNC('quarter', [Transaction Date])))
  4. DATEADD('month', 3, DATETRUNC('quarter', [Transaction Date]))
Explanation: When working with date calculations in Tableau, a reliable pattern for finding period-end dates is: truncate to get the period's start, shift forward one period, then subtract one day. Memorizing this three-step sequence will carry you through many date-boundary problems. Answer B follows this pattern exactly. DATETRUNC('quarter', [Transaction Date]) snaps any date to the first day of its quarter — say, October 1 for a date in Q4. DATEADD('quarter', 1, ...) then advances that to January 1 of the next quarter. Finally, DATEADD('day', -1, ...) steps back one day to December 31 — the true last day of Q4. The logic is clean and handles every quarter correctly, including year boundaries. Answer A makes the subtraction without ever advancing to the next quarter, so it returns the day before the quarter starts — the last day of the previous quarter, not the current one. Answer C reverses the order of operations in a critical way: it subtracts a day from the quarter-start before advancing by a quarter. That lands you one day before the end of the quarter, not on the last day itself — off by one for every input date. Answer D adds exactly three months to the quarter-start, which lands on the first day of the next quarter, not the last day of the current one. Forgetting the final -1 day adjustment is a very common trap. The strategy to remember: start → next boundary → back one day. Any shortcut that skips or reorders these steps will silently return a wrong date.

Question 2

A view contains sales from 2024 through 2026. The analyst needs one chronologically ordered mark for each calendar month, with January 2024, January 2025, and January 2026 shown as separate periods.

Which calculated field should the analyst use as the monthly time-series dimension?

  1. DATEPART('month', [Order Date]), used as a discrete numeric dimension
  2. DATENAME('month', [Order Date]), used as a discrete text dimension
  3. DATETRUNC('year', [Order Date]), used as a continuous date dimension
  4. DATETRUNC('month', [Order Date]), used as a continuous date dimension (correct answer)
Explanation: When building a time-series view in Tableau, ask yourself two questions: does this field distinguish every unique period I need, and does it sort chronologically? Both conditions must be true simultaneously. DATETRUNC('month', [Order Date]) satisfies both requirements, making D the right choice. It truncates each date to the first day of its month — so March 15, 2024 becomes March 1, 2024, and March 15, 2025 becomes March 1, 2025. Because these are distinct date values, January 2024, January 2025, and January 2026 appear as three separate marks. Used as a continuous date axis, Tableau plots them in natural calendar order automatically. A fails on the first condition: DATEPART('month', [Order Date]) returns a plain integer (1–12). January 2024 and January 2025 both return 1, so they collapse into a single mark — exactly what the analyst needs to avoid. You lose the year entirely. B has the same problem as A. DATENAME('month', [Order Date]) returns a text string like "January" — no year information whatsoever. All three Januaries merge, and text dimensions sort alphabetically, not chronologically, so "April" precedes "January." C uses DATETRUNC('year', ...), which truncates to January 1 of each year. This gives you one mark per year (2024, 2025, 2026) — three marks total, but each representing an entire year, not each individual calendar month. A useful rule of thumb: match the DATETRUNC level to the granularity you want displayed. Monthly marks → 'month'; yearly marks → 'year'. This pattern appears frequently on the Tableau exam.

Question 3

A data source contains [Birth Date], and a date parameter [As Of Date] supplies the date on which age must be measured. The calculation must return completed years, not merely the difference between calendar-year numbers.

Which calculation correctly adjusts the age when the birthday has not yet occurred during the as-of year?

  1. DATEDIFF('year', [Birth Date], [As Of Date]) - IIF(DATEADD('year', DATEDIFF('year', [Birth Date], [As Of Date]), [Birth Date]) > [As Of Date], 1, 0) (correct answer)
  2. DATEDIFF('year', [Birth Date], [As Of Date]) - IIF(DATETRUNC('year', [Birth Date]) > DATETRUNC('year', [As Of Date]), 1, 0)
  3. DATEDIFF('year', [Birth Date], [As Of Date]) + IIF(DATEADD('year', DATEDIFF('year', [Birth Date], [As Of Date]), [Birth Date]) > [As Of Date], 1, 0)
  4. DATEDIFF('year', [Birth Date], [As Of Date]) - IIF(DATEPART('year', [Birth Date]) > DATEPART('year', [As Of Date]), 1, 0)
Explanation: Calculating completed age requires more than subtracting calendar years — you need to check whether the birthday has actually occurred yet in the as-of year. The core idea: start with DATEDIFF('year', ...) to get the raw year difference, then subtract 1 if the birthday hasn't happened yet. The reliable way to test "has the birthday occurred?" is to reconstruct what the birthday would be in the as-of year, then compare it to the as-of date. Answer A does exactly this: DATEADD('year', DATEDIFF('year', [Birth Date], [As Of Date]), [Birth Date]) projects the birth date forward by the raw year difference, landing on the birthday in the as-of year. If that projected birthday is greater than [As Of Date], the birthday hasn't occurred yet, so we subtract 1. This correctly handles edge cases like leap-year birthdays. Answer B is wrong because DATETRUNC('year', [Birth Date]) always truncates to January 1 of the birth year, which is always less than DATETRUNC('year', [As Of Date]) (assuming the person is alive), so the IIF condition is almost never true — the adjustment never fires correctly. Answer C uses the right comparison logic but adds 1 instead of subtracting it. If the birthday hasn't occurred, you'd be overcounting age by 1, not correcting it. Answer D compares the raw birth year number to the as-of year number, which is always false for living people (you can't be born after the as-of year), so the correction never applies. When you see age calculations on the Tableau exam, remember: project the birthday forward, then compare — DATEADD + DATEDIFF is your precision tool, not DATEPART or DATETRUNC.

Question 4

A company defines every week as Monday through Sunday, regardless of the workbook or data source's default start-of-week setting. A record has the date #2025-07-09#, which is a Wednesday.

Which calculation and result correctly identify the beginning of that record's company week?

  1. DATETRUNC('week', #2025-07-09#, 'monday'), returning #2025-07-07# (correct answer)
  2. DATETRUNC('week', #2025-07-09#, 'sunday'), returning #2025-07-06#
  3. DATEADD('day', -7, #2025-07-09#), returning #2025-07-02#
  4. DATETRUNC('week', #2025-07-09#), returning #2025-07-09#
Explanation: When working with date truncation in Tableau, the key question is always: which week boundary does Tableau use? By default, Tableau truncates weeks to Sunday, but many businesses define weeks differently — and DATETRUNC lets you override that with an optional third argument specifying the start-of-week day. Since the company defines weeks as Monday–Sunday, you need to truncate to the nearest Monday on or before the record date. For #2025-07-09# (a Wednesday), counting back to Monday lands on #2025-07-07#. The calculation DATETRUNC('week', #2025-07-09#, 'monday') does exactly this — the 'monday' argument tells Tableau to treat Monday as the first day of the week, so A is correct. Choice B uses 'sunday' as the start-of-week argument, which returns #2025-07-06# (the preceding Sunday). That's Tableau's default behavior, not the company's Monday-based definition — a common trap when the question specifies a custom fiscal or company calendar. Choice C uses DATEADD to subtract seven days, producing #2025-07-02#, which is simply one week earlier and has nothing to do with finding the week's start — it's the wrong function entirely. Choice D calls DATETRUNC without the optional third argument, so Tableau falls back to its default Sunday start, and since July 6 is a Sunday, the truncation would return #2025-07-06#, not the date itself — making D wrong both in logic and in the stated result. Your study tip: whenever a question mentions a company-defined or non-standard week, immediately look for DATETRUNC with the explicit start-of-week argument. If that argument is missing or wrong, the answer is a distractor.

Question 5

A timestamp field [Event Time] must be filtered into seven complete calendar-date buckets: the current date and the preceding six dates. The calculation should use midnight boundaries and should not behave as a rolling 168-hour window.

Which filter calculation correctly defines those seven calendar dates?

  1. [Event Time] >= DATEADD('day', -7, NOW()) AND [Event Time] <= NOW()
  2. [Event Time] >= DATEADD('day', -7, DATETRUNC('day', NOW())) AND [Event Time] < DATETRUNC('day', NOW())
  3. [Event Time] >= DATEADD('day', -6, DATETRUNC('day', NOW())) AND [Event Time] < DATEADD('day', 1, DATETRUNC('day', NOW())) (correct answer)
  4. [Event Time] > DATEADD('day', -6, NOW()) AND [Event Time] < DATEADD('day', 1, NOW())
Explanation: When filtering timestamp data into calendar-date buckets, the critical distinction is between a rolling time window (measured in hours from right now) and true midnight-bounded dates. These are not the same thing, and this question tests whether you can tell them apart. The correct approach in C anchors everything to DATETRUNC('day', NOW()), which represents today's midnight — call it T. The lower bound becomes DATEADD('day', -6, T), which is six midnights ago (the start of the earliest of your seven days). The upper bound is DATEADD('day', 1, T), the start of tomorrow, used with a strict less-than so today's full day is included but tomorrow is excluded. That gives you exactly seven complete calendar days: today plus the six before it. A is wrong on two counts: it uses NOW() (the current moment) instead of DATETRUNC, so boundaries float with the clock rather than snapping to midnight. It also spans seven days back from now, which yields a 168-hour rolling window — precisely what the question says to avoid. B correctly uses DATETRUNC for both bounds, but its upper bound is DATETRUNC('day', NOW()) — today's midnight — which means today itself is entirely excluded. You'd get only six complete days, and the current date would be missing. D reintroduces the rolling-window problem by using raw NOW() in both bounds instead of DATETRUNC. The boundaries drift throughout the day and never represent true calendar dates. The key habit to build: whenever a spec says "calendar date," immediately reach for DATETRUNC('day', ...) to lock your boundaries to midnight, then use DATEADD to shift those fixed anchors.

Question 6

An organization reports by ISO weeks. It uses DATEPART('iso-week', [Date]) for the week number and DATEPART('iso-year', [Date]) for the associated year.

For the date #2021-01-01#, which ISO week and ISO year will Tableau return?

  1. ISO week 1 and ISO year 2021\text{ISO week }1\text{ and ISO year }2021
  2. ISO week 1 and ISO year 2020\text{ISO week }1\text{ and ISO year }2020
  3. ISO week 53 and ISO year 2021\text{ISO week }53\text{ and ISO year }2021
  4. ISO week 53 and ISO year 2020\text{ISO week }53\text{ and ISO year }2020 (correct answer)
Explanation: When working with ISO week dates in Tableau, the critical concept to understand is that ISO weeks and calendar years don't always align. The ISO 8601 standard defines Week 1 as the week containing the first Thursday of the year. This means dates in late December or early January can "belong" to a different ISO year than their calendar year. For #2021-01-01#, that date falls on a Friday. The week containing that Friday has its Thursday on December 31, 2020 — meaning the entire week belongs to ISO year 2020. Since December 28, 2020 was the last Monday before that Thursday, this week is counted as Week 53 of ISO year 2020. So DATEPART('iso-week', #2021-01-01#) returns 5353 and DATEPART('iso-year', #2021-01-01#) returns 20202020, confirming D is correct. A is wrong on both counts — it assumes the calendar year and ISO year always match, and that January 1st always starts a new ISO week. Neither is guaranteed. B gets the ISO year right (2020) but assigns Week 1, incorrectly assuming January 1st resets the week counter regardless of the day of the week. C gets the week number right (53) but assigns ISO year 2021, which is the classic trap of mixing up the calendar year with the ISO year. A useful tip: whenever you see a date within the first or last week of January or December, always verify the ISO year separately — it may differ from what YEAR([Date]) would return, which is why Tableau provides iso-year as its own distinct date part.

Question 7

A text field contains 04/05/2025. The documented format is day/month/year, so the value represents May 4, 2025. The analyst needs the first day of that value's month.

Which calculation returns #2025-05-01#?

  1. DATETRUNC('month', DATEPARSE('MM/dd/yyyy', [Date Text]))
  2. DATETRUNC('year', DATEPARSE('dd/MM/yyyy', [Date Text]))
  3. DATETRUNC('month', DATEPARSE('dd/MM/yyyy', [Date Text])) (correct answer)
  4. DATEADD('month', -1, DATEPARSE('dd/MM/yyyy', [Date Text]))
Explanation: When working with date calculations in Tableau, questions like this test two distinct skills simultaneously: parsing a string into a date using the correct format pattern, and then truncating that date to a specific granularity. You need to get both steps right. The string 04/05/2025 follows day/month/year format, meaning day=04, month=05, year=2025 — that's May 4, 2025. The correct format string for DATEPARSE is therefore 'dd/MM/yyyy', where lowercase dd captures the day and uppercase MM captures the month. Once parsed correctly, DATETRUNC('month', ...) snaps the date back to the first day of its month, producing #2025-05-01#. That's exactly what C does — making it the correct answer. A fails at the parsing step. Using 'MM/dd/yyyy' treats 04 as the month and 05 as the day, producing April 5 instead of May 4. Truncating that to the month gives #2025-04-01#, not the intended result. B parses the date correctly with 'dd/MM/yyyy', but then applies DATETRUNC('year', ...) instead of 'month'. Truncating to the year returns #2025-01-01# — the first day of the year, not the month. D also parses correctly, but DATEADD('month', -1, ...) subtracts one month from May 4, returning #2025-04-04#. That's neither the first of the month nor the correct month. A useful pattern to remember: on format strings, MM = month, dd = day — mixing them up is the most common trap. Always confirm the documented format before writing your DATEPARSE pattern.

Question 8

A workbook is evaluated at 2026-07-09 15:00:00. A case was opened at 2026-07-08 09:00:00. Assume no time-zone conversion.

What values are returned by DATEDIFF('hour', [Opened At], NOW()) and DATEDIFF('hour', [Opened At], TODAY()), respectively?

  1. 30 hours and 15 hours30\text{ hours and }15\text{ hours} (correct answer)
  2. 30 hours and 24 hours30\text{ hours and }24\text{ hours}
  3. 15 hours and 30 hours15\text{ hours and }30\text{ hours}
  4. 15 hours and 15 hours15\text{ hours and }15\text{ hours}
Explanation: When working with DATEDIFF in Tableau, the critical distinction to understand is that NOW() returns the current datetime (with a time component), while TODAY() returns midnight of the current date — essentially 2026-07-09 00:00:00. For DATEDIFF('hour', [Opened At], NOW()), you're measuring from 2026-07-08 09:00:00 to 2026-07-09 15:00:00. That span is 24 hours (one full day) plus 6 additional hours, giving you 24+6=30 hours24 + 6 = 30 \text{ hours}. For DATEDIFF('hour', [Opened At], TODAY()), the end point is 2026-07-09 00:00:00 (midnight), so the span from 2026-07-08 09:00:00 to midnight is exactly 15 hours15 \text{ hours}. This confirms answer A: 30 hours and 15 hours. Answer B (30 and 24) misunderstands TODAY() — treating it as if it means "24 hours ago" or a full day boundary rather than the specific moment of midnight. Answer C (15 and 30) simply swaps the two results, confusing which function produces which value. Answer D (15 and 15) incorrectly assumes both functions return the same value, ignoring that NOW() captures the actual time of day. The key study tip here: always treat TODAY() as midnight, not "the current moment." A helpful mnemonic is that TODAY() has no clock — it strips the time entirely, anchoring to 00:00:00. On the exam, whenever you see both functions in the same question, immediately ask yourself whether the time-of-day component matters for that calculation.

Question 9

A workbook is refreshed on 2025-03-15. An analyst must filter orders to the previous complete calendar month, regardless of the day on which the workbook is refreshed.

Which Tableau calculation most reliably returns TRUE only for orders from February 2025?

  1. [Order Date] >= DATEADD('month', -1, TODAY()) AND [Order Date] < TODAY()
  2. DATETRUNC('month', [Order Date]) = DATEADD('month', -1, DATETRUNC('month', TODAY())) (correct answer)
  3. [Order Date] >= DATEADD('day', -30, TODAY()) AND [Order Date] < TODAY()
  4. DATETRUNC('month', [Order Date]) = DATETRUNC('month', DATEADD('day', -1, TODAY()))
Explanation: When filtering for a "previous complete calendar month," you need to think carefully about two things: anchoring to month boundaries (not arbitrary day offsets), and consistency regardless of the refresh date. The key tool in Tableau for this is DATETRUNC, which snaps a date to the start of a specified period. The reliable approach is B. DATETRUNC('month', [Order Date]) returns the first day of each order's month. DATEADD('month', -1, DATETRUNC('month', TODAY())) takes today's month-start (March 1, 2025) and subtracts one month, yielding February 1, 2025. So the filter asks: "Does this order's month-start equal February 1, 2025?" — which is exactly true for all February orders and only February orders. A is wrong because DATEADD('month', -1, TODAY()) subtracts one month from the current day (March 15 → February 15), not from the month boundary. This would miss February 1–14 entirely and include dates up to the current day — not a complete month. C is wrong because a 30-day lookback is date-range approximate, not calendar-month aware. February has 28 or 29 days, and the window shifts every day the workbook is open, making this unreliable for capturing exactly one complete prior month. D is subtly wrong. DATEADD('day', -1, TODAY()) gives March 14, and DATETRUNC('month', March 14) gives March 1 — meaning the filter compares order months to March, not February. Study tip: Whenever a question asks for a "complete prior period," look for DATETRUNC combined with DATEADD on the period unit (not days). Day-based offsets are almost always a trap.