Tableau Quiz: Data Types
9 questions · exam conditions
0:00
Data TypesQuestion 1 of 9

A support-ticket source provides [Opened At] and [Closed At] with values such as 2025-08-01 23:50:00 and 2025-08-02 00:20:00. After both fields are changed to Date, DATEDIFF('minute', [Opened At], [Closed At]) returns an incorrect result because the time portions are no longer available.

What is the appropriate correction?

Parse or assign both fields as Date & Time, then calculate the minute difference.
Keep both fields as Date and change the date display format to include hours and minutes.
Convert both fields to String and subtract the formatted timestamp strings from one another.
Keep both fields as Date and calculate the day difference before formatting it as minutes.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Data Types

Practice Data Types 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 Data Types, 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

A support-ticket source provides [Opened At] and [Closed At] with values such as 2025-08-01 23:50:00 and 2025-08-02 00:20:00. After both fields are changed to Date, DATEDIFF('minute', [Opened At], [Closed At]) returns an incorrect result because the time portions are no longer available.

What is the appropriate correction?

  1. Parse or assign both fields as Date & Time, then calculate the minute difference. (correct answer)
  2. Keep both fields as Date and change the date display format to include hours and minutes.
  3. Convert both fields to String and subtract the formatted timestamp strings from one another.
  4. Keep both fields as Date and calculate the day difference before formatting it as minutes.
Explanation: When working with date and time calculations in Tableau, the data type of your fields determines what information is actually stored and available for computation. If a field containing timestamp data (both date and time) is cast as Date only, Tableau discards the time portion entirely — treating 2025-08-01 23:50:00 and 2025-08-02 00:20:00 as simply 2025-08-01 and 2025-08-02. Any minute-level calculation then becomes meaningless, because the underlying granularity no longer exists. The fix is straightforward: parse or assign both fields as Date & Time (also called datetime). This preserves the full timestamp, so DATEDIFF('minute', [Opened At], [Closed At]) correctly returns 30 minutes instead of the misleading 1-day equivalent. That's why A is the right answer — it restores the data type that the calculation actually requires. B is a common trap: changing the display format of a Date field to show hours and minutes is purely cosmetic. It makes the field look like a datetime without actually storing time data, so calculations remain wrong. C is a fundamental misunderstanding — string subtraction is not a valid operation in Tableau, and formatted strings cannot replace proper datetime arithmetic. D fails because keeping the Date type and converting day differences to minutes produces a coarse approximation (whole days × 1,440) that ignores the real elapsed minutes and is mathematically incorrect for this scenario. As a study tip: on Tableau exam questions involving time-based calculations, always verify the data type first. Display format and data type are separate concerns, and confusing them is one of the most common sources of incorrect results in practice.

Question 2

A String field contains timestamps such as 2025-07-09T16:04:27.125Z. The T and Z are literal characters, the hour uses a 24-hour clock, and the final three digits are milliseconds.

Which expression uses an appropriate explicit pattern to parse the field as a datetime?

  1. DATEPARSE("yyyy-mm-dd'T'hh:MM:ss.SSS'Z'", [Timestamp Text])
  2. DATEPARSE("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", [Timestamp Text]) (correct answer)
  3. DATEPARSE("yyyy-MM-dd HH:mm:ss", REPLACE([Timestamp Text], "Z", ""))
  4. DATEPARSE("dd-MM-yyyy'T'HH:mm:ss.SSS'Z'", [Timestamp Text])
Explanation: When working with DATEPARSE in Tableau, your job is to match every character in the format string to the corresponding part of the raw text — and the format tokens are case-sensitive in ways that matter enormously. The timestamp 2025-07-09T16:04:27.125Z has a specific anatomy: a four-digit year, two-digit month, two-digit day, a literal T, a 24-hour hour, minutes, seconds, milliseconds, and a literal Z. For literal characters that aren't format tokens, you wrap them in single quotes. For milliseconds, SSS is the correct token. That logic maps perfectly to "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" — making B correct. Here's where the distractors trip you up. A uses mm in the month position and hh for the hour. In Java-style date formatting (which Tableau follows), mm means minutes, not months — months require uppercase MM. Worse, hh is a 12-hour clock token; since the data uses a 24-hour clock, you need HH. A misassigns both. C avoids the issue of quoting literal characters by stripping the Z with REPLACE, but it also drops the entire time-precision portion — the pattern "yyyy-MM-dd HH:mm:ss" ignores milliseconds and assumes a space separator instead of T, so it will fail to parse the string even after the replacement. D has the right tokens for time but reverses the date order to dd-MM-yyyy, which doesn't match the year-first ISO 8601 structure of the source data. A reliable memory trick: MM = Months (uppercase, like a proper noun), mm = minutes (lowercase, smaller unit), and HH always means 24-hour. Drill this case-sensitivity — it's one of the most common DATEPARSE traps on the exam.

Question 3

A database column contains 18-digit account identifiers. Tableau receives the column as a numeric type, and some identifiers appear with altered final digits. The identifiers are used only for exact matching and never for arithmetic.

Which approach best prevents further precision loss and preserves exact relationship keys?

  1. Cast the database column to a character type in the query or source before Tableau reads it. (correct answer)
  2. Keep the column numeric and increase the displayed number of decimal places in Tableau.
  3. Convert the already rounded Tableau numeric field to String and use the resulting text as the key.
  4. Keep the column numeric and assign it the Identifier geographic role before creating relationships.
Explanation: When Tableau ingests a numeric column, it stores values as 64-bit floating-point numbers, which can only represent about 15–16 significant decimal digits precisely. An 18-digit account identifier exceeds that limit, so Tableau silently rounds the trailing digits — meaning the damage happens at the moment of ingestion, before you ever interact with the field. The only reliable fix is to prevent Tableau from treating those digits as a number in the first place. Option A does exactly that: by casting the column to a character/text type at the database or query level, the identifier is transmitted as a string of characters, not a floating-point value. No arithmetic representation ever occurs, so no precision is lost — every digit arrives intact and can be used for exact matching. Option B is a common misconception. Displaying more decimal places doesn't recover precision; it just shows more digits of an already-corrupted stored value. The rounding happened in memory, not in the display format. Option C sounds appealing but is fatally flawed: it converts a field that has already been rounded into a string. You're preserving a broken value — the final digits are already wrong. Converting downstream doesn't undo upstream precision loss. Option D is a distractor that conflates geographic roles with data type handling. Geographic roles affect how Tableau maps or visualizes data; they have no effect on floating-point precision. The strategic takeaway: whenever you see identifiers, codes, or keys stored as numbers, your instinct should be "this should be a string." Precision loss at ingestion is irreversible — fix it at the source, not after the fact.

Question 4

A String field named [Batch Code] contains values such as 20250709-A and 20251231-B. The first eight characters always represent a date in year-month-day order, with no separators.

Which calculation returns the embedded value as a date-compatible field?

  1. DATEPARSE("MMDDyyyy", LEFT([Batch Code], 8))
  2. DATEPARSE("yyyyMMdd", RIGHT([Batch Code], 8))
  3. DATEPART("yyyyMMdd", LEFT([Batch Code], 8))
  4. DATEPARSE("yyyyMMdd", LEFT([Batch Code], 8)) (correct answer)
Explanation: When converting a string to a date in Tableau, your go-to function is DATEPARSE, which takes two arguments: a format string that describes the pattern of your date text, and the string itself. The format string uses tokens like yyyy (four-digit year), MM (two-digit month), and dd (two-digit day) — and the order of those tokens must exactly match the order of characters in your string. Your batch code starts with eight characters in year-month-day order (e.g., 20250709), so the correct format string is "yyyyMMdd". You also need LEFT([Batch Code], 8) to extract those first eight characters. That's precisely what D does — making it the correct answer. A is wrong on two counts: it uses "MMDDyyyy" (month-day-year order, which doesn't match), and it also uses an incorrect token DD — Tableau's format uses lowercase dd for day. B uses the right format string "yyyyMMdd" but calls RIGHT([Batch Code], 8) instead of LEFT. Since the date is at the beginning of the string, RIGHT would pull characters that include the -A suffix, breaking the parse entirely. C uses DATEPART instead of DATEPARSE — DATEPART extracts a numeric component (like the year or month) from an existing date field, not from a string. It's the wrong function for this job entirely. A useful tip: on Tableau exam questions involving string-to-date conversion, always check three things — correct function (DATEPARSE), correct extraction side (LEFT vs. RIGHT), and correct format token order matching the actual string layout.

Question 5

A text field named [Order Date Text] contains two valid formats: 2025-07-14 and 07/15/2025. The workbook must produce one date-compatible field without relying on the computer's regional date settings.

Which calculated field most reliably parses both formats?

  1. DATE([Order Date Text]), allowing Tableau to infer the format for every row
  2. IF CONTAINS([Order Date Text], "-") THEN DATEPARSE("yyyy-MM-dd", [Order Date Text]) ELSE DATEPARSE("MM/dd/yyyy", [Order Date Text]) END (correct answer)
  3. DATEPARSE("yyyy-MM-dd", REPLACE([Order Date Text], "/", "-")), using one pattern after replacing separators
  4. IF CONTAINS([Order Date Text], "/") THEN DATEPARSE("dd/MM/yyyy", [Order Date Text]) ELSE DATE([Order Date Text]) END
Explanation: When parsing mixed date formats in Tableau, your first instinct should be to ask: does every row share the same structure? If not, you need logic that identifies the format before parsing — and that's exactly what this question tests. The reliable solution is B. It uses CONTAINS to detect which format each row uses, then routes it to the appropriate DATEPARSE call with an explicit format string. Because DATEPARSE ignores regional settings entirely, it produces consistent results regardless of the user's locale — exactly what the question requires. A fails because DATE() leans on Tableau's implicit type-casting, which in turn depends on the computer's regional date settings. On a machine configured for day-first dates, 07/15/2025 could be misread or return null. This is precisely the dependency the question asks you to avoid. C seems clever — replace / with - so everything looks like 2025-07-14 — but it breaks on the slash-format dates. 07/15/2025 becomes 07-15-2025, which doesn't match the pattern yyyy-MM-dd (it would need MM-dd-yyyy). One separator, two different orderings of year/month/day means a single DATEPARSE call still can't handle both. D contains a critical error: it applies "dd/MM/yyyy" to slash-format dates, but 07/15/2025 is in MM/dd/yyyy order. Day 15 of month 07 works, but any date where the day exceeds 12 would either fail or silently produce a wrong date. Study tip: On Tableau parsing questions, always check two things — does the solution handle format detection row by row? and does it eliminate regional setting dependency? If either answer is no, keep looking.

Question 6

A packaged workbook contains an extract in which postal codes were stored as whole numbers. The original value 02108 is stored in the extract as 2108. The raw CSV is still available and contains the leading zero.

Which action will reliably restore the postal codes while assigning the appropriate data type?

  1. Change the extracted field to String and apply a five-character custom number format.
  2. Convert the extracted field to Date and then change the resulting values to String.
  3. Reconnect to the raw CSV, assign the column a String type, and rebuild the extract. (correct answer)
  4. Keep the extracted field numeric and use an alias to display a zero before each value.
Explanation: When Tableau reads a numeric column, it strips leading zeros because integers simply don't store them — 02108 becomes 2108 with no recoverable trace inside the extract. Fixing this requires going back to the data source and telling Tableau to treat the column as text before the extract is built, so the leading zero is preserved from the start. That's exactly what C does: reconnecting to the raw CSV lets you set the postal code column to String at the source level, after which rebuilding the extract captures 02108 as a true five-character string. The data is correct at every layer — source, extract, and visualization. A is tempting but flawed: a custom number format can display a leading zero visually, but the underlying field remains a number. Any calculation, join, or export that references the raw value will still see 2108, not 02108, making this a cosmetic fix rather than a real one. B is a nonsensical path — converting a postal code to a Date type produces errors or meaningless results; there's no logical intermediate step that yields a clean string. D has the same core problem as A: aliases only change the display label in a dimension, not the stored value, so the data integrity issue persists downstream. The key principle to remember is that data type decisions must be made at the source, not patched afterward. Whenever a question asks you to "restore" or "correct" data that was misinterpreted during ingestion, the reliable fix is always to return to the source, apply the right type, and reload — not to apply a visual workaround on top of bad data.

Question 7

An Orders table stores [Customer ID] as a whole number, such as 42. A Customers table stores the corresponding key as a five-character String, such as 00042. Changing the Orders field directly to String produces 42, so the relationship does not match.

Which preparation creates a compatible relationship key without changing the Customers table?

  1. Convert the Customers key to a whole number and retain its five-character display format.
  2. Apply a five-digit number format to the Orders key and keep its data type numeric.
  3. Create RIGHT("00000" + STR([Customer ID]), 5) in Orders and relate it to the String key. (correct answer)
  4. Create LEFT(STR([Customer ID]) + "00000", 5) in Orders and relate it to the String key.
Explanation: When building relationships across tables in Tableau, the joined fields must match exactly — same data type and same formatted value. Here, the challenge is padding a numeric [Customer ID] like 42 into the zero-padded string "00042" that the Customers table expects. The reliable approach is to concatenate enough leading zeros and then trim to exactly five characters from the right. RIGHT("00000" + STR([Customer ID]), 5) works by first converting 42 to "42", prepending five zeros to get "0000042", then taking the rightmost five characters: "00042". This perfectly matches the Customers key, making C the correct answer. A is flawed because it modifies the Customers table, which the question explicitly prohibits, and converting to a whole number drops leading zeros entirely — 00042 becomes 42. B is a common trap. Applying a display format to a numeric field changes how it looks in a viz, but Tableau still uses the underlying numeric value 42 when evaluating relationship matches against a string "00042". Format masks never affect join logic. D uses LEFT instead of RIGHT, which produces the wrong end of the padded string. LEFT("4200000", 5) gives "42000" — the opposite of what you need. A good rule of thumb: when zero-padding strings, always anchor to the right side of the padded value, which is why RIGHT is your go-to function. Also remember that visual formatting in Tableau is purely cosmetic and never influences how relationship keys are compared.

Question 8

A whole-number field named [Epoch Milliseconds] stores Unix timestamps in milliseconds, such as a 13-digit value. The required result is a Tableau datetime based on the Unix epoch.

Which calculation applies the correct unit conversion before creating the datetime?

  1. DATEADD('second', [Epoch Milliseconds], #1970-01-01 00:00:00#)
  2. DATEADD('millisecond', [Epoch Milliseconds], #1900-01-01 00:00:00#)
  3. DATEADD('second', INT([Epoch Milliseconds] / 1000), #1970-01-01 00:00:00#) (correct answer)
  4. DATETIME(STR([Epoch Milliseconds] / 1000))
Explanation: When converting Unix timestamps in Tableau, you need to understand two things: what the Unix epoch is, and what unit your raw data is in. Unix time counts seconds elapsed since January 1, 1970, 00:00:00 UTC — that's your anchor date. If your field stores milliseconds, you must divide by 1,000 before passing the value to DATEADD as seconds. C is correct because it does exactly this. INT([Epoch Milliseconds] / 1000) converts milliseconds to whole seconds, and DATEADD('second', ..., #1970-01-01 00:00:00#) adds those seconds to the correct Unix epoch origin, producing a valid Tableau datetime. A skips the unit conversion entirely — it passes raw millisecond values as if they were seconds. A 13-digit number treated as seconds would place your date thousands of years in the future, not in the modern era. B makes two mistakes at once: it uses 'millisecond' as the date part, which Tableau's DATEADD does not support as a valid unit, and it anchors to January 1, 1900 — the Excel/Tableau serial date origin — rather than the Unix epoch of 1970. D attempts a type-cast shortcut using DATETIME(STR(...)), but STR() converts a number to a string, and DATETIME() cannot reliably parse an arbitrary numeric string into a meaningful date — this will return null or an error. As a study tip, remember the two-part checklist for Unix timestamp conversions: ① divide milliseconds by 1,000 to get seconds, and ② always anchor to #1970-01-01 00:00:00#. Mixing up the epoch origin or skipping the unit conversion are the two most common traps on this type of question.

Question 9

A String field named [Reading Text] contains valid numeric text such as 18.6, the literal value unknown, and true source nulls. Analysts need a numeric measure while still distinguishing invalid text from values that were missing in the source.

Which preparation strategy best satisfies both requirements?

  1. Change [Reading Text] directly to Number and classify every resulting null as source-missing data.
  2. Retain [Reading Text], create FLOAT([Reading Text]), and separately classify null originals versus failed conversions. (correct answer)
  3. Replace both unknown and source nulls with 0, then change the original field to Number.
  4. Retain [Reading Text] as String and format it as a decimal measure without numeric conversion.
Explanation: When working with mixed-content string fields in Tableau, your goal is to preserve information rather than collapse it. Ask yourself: what distinctions does the analyst need to maintain downstream? Here, two separate conditions matter — values that were never recorded (source nulls) and values that were recorded but meaningless (like "unknown"). Any strategy that merges these two conditions loses analytical precision. Option B is correct because it uses a two-layer approach. Retaining [Reading Text] as the original string preserves the raw state of every record. Then, FLOAT([Reading Text]) performs the numeric conversion: valid text like "18.6" becomes 18.6, while "unknown" becomes null due to a failed cast. Now you have two null-producing scenarios you can distinguish — records where the original string was already null (source-missing) versus records where the original string existed but conversion failed (invalid text). A calculated field checking ISNULL([Reading Text]) separates these cleanly. Option A fails because converting the field directly destroys the original string, making it impossible to tell whether a resulting null came from a source gap or a failed parse — exactly the distinction the analysts need. Option C is worse still: replacing nulls and "unknown" with 0 actively fabricates numeric data, corrupting the measure entirely. A missing reading and an invalid reading are not zero readings. Option D is a trap — you cannot format a string field as a numeric measure in Tableau. String fields don't participate in aggregations like SUM or AVG regardless of how they're formatted. The key study tip: when a question involves preserving distinctions between data quality categories, the right strategy almost always involves keeping the original field and deriving a new one — never overwriting the source.