R Programming Quiz: Lubridate Functions
10 questions · exam conditions
0:00
Lubridate FunctionsQuestion 1 of 10

A character value contains a day-first date followed by hours and minutes but no seconds:

stamp <- "31-01-2025 18:45"

Which call is designed to parse the complete value without requiring seconds?

lubridate::dmy_hm(stamp), using day-month-year and hour-minute order
lubridate::dmy_hms(stamp), using day-month-year and hour-minute-second order
lubridate::ymd_hm(stamp), using year-month-day and hour-minute order
lubridate::mdy_hm(stamp), using month-day-year and hour-minute order
← Back to quizzes

R Programming Quiz

R Programming Quiz: Lubridate Functions

Practice Lubridate Functions in R Programming 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 Lubridate Functions, giving you a quick way to practice the rules, question types, and explanations that matter most for R Programming.

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 character value contains a day-first date followed by hours and minutes but no seconds:

stamp <- "31-01-2025 18:45"

Which call is designed to parse the complete value without requiring seconds?

  1. lubridate::dmy_hm(stamp), using day-month-year and hour-minute order (correct answer)
  2. lubridate::dmy_hms(stamp), using day-month-year and hour-minute-second order
  3. lubridate::ymd_hm(stamp), using year-month-day and hour-minute order
  4. lubridate::mdy_hm(stamp), using month-day-year and hour-minute order
Explanation: When parsing datetime strings with lubridate, you need to match two things simultaneously: the order of date components and the time components present. The function name encodes both, so reading it carefully is the entire task. The string "31-01-2025 18:45" opens with day, then month, then year — that's dmy order. The time portion contains only hours and minutes, with no seconds — that's hm, not hms. Putting those together, lubridate::dmy_hm(stamp) maps perfectly onto the string's structure, making A the correct choice. B fails because dmy_hms expects a seconds component (e.g., "18:45:00"). When seconds are absent from the string, this function will either throw a parsing warning or return NA — it won't silently succeed. C uses ymd_hm, which correctly handles hour-minute time but assumes the date begins with the year. Applied to "31-01-2025", it would try to interpret 31 as a year, which fails. D uses mdy_hm, which expects the month first. Since 31 cannot be a valid month, this also fails to parse. A useful study tip: treat lubridate function names as a two-part checklist. Before choosing a function, write out the date order you see (day first? year first?) and count the time fields (two fields = hm, three fields = hms). This eliminates all four distractors mechanically, without needing to memorize which specific function handles which edge case.

Question 2

A vector combines two known formats:

raw <- c("2024-05-06", "07/05/2024")

The first element uses year-month-day order, and the second uses day-month-year order. Which expression reliably creates dates for May 6 and May 7, 2024, in that order?

  1. lubridate::dmy(raw), applying the second element's order to both values
  2. lubridate::ymd(raw), allowing each separator to determine its date order
  3. c(lubridate::ymd(raw[1]), lubridate::dmy(raw[2])) (correct answer)
  4. c(lubridate::ydm(raw[1]), lubridate::mdy(raw[2]))
Explanation: When working with date parsing in R, the core challenge is that a single parsing function assumes one fixed format for every element in the vector — which breaks down the moment your data mixes formats. lubridate functions like ymd(), dmy(), and mdy() each enforce a specific order of date components (year-month-day, day-month-year, etc.), regardless of the separator used. So if you pass a mixed-format vector to any single function, it will misparse at least one element. Option C is correct because it handles each element individually with the right parser: lubridate::ymd(raw[1]) correctly reads "2024-05-06" as May 6, 2024, and lubridate::dmy(raw[2]) correctly reads "07/05/2024" as May 7, 2024. Wrapping both in c() then combines them into a single Date vector with both values correctly parsed. Option A fails because applying dmy() to the entire vector forces day-month-year logic onto "2024-05-06", producing an incorrect or NA result — the year 2024 cannot be a valid day. Option B is a common misconception: ymd() does not adapt its ordering based on separators. The separator (- vs /) is irrelevant to component order, so ymd() would misparse "07/05/2024" as July 5, not May 7. Option D uses ydm() on the first element, which reads it as year-day-month and would return May 6 only by coincidence in some cases — it's not reliable — and mdy() on the second reads "07/05/2024" as July 5, 2024, which is wrong. As a rule of thumb: when your date strings mix formats, parse each group separately with the matching lubridate function, then combine results.

Question 3

Consider the following code:

x <- c("12-01-2024", "12/01/2024", "12.01.2024") dates <- lubridate::mdy(x)

Which result should be expected?

  1. All three values parse as December 1, 2024 despite their different separators. (correct answer)
  2. Only the hyphenated and slashed values parse; the dotted value becomes NA.
  3. All three values parse as January 12, 2024 because separators determine the order.
  4. Only the slashed value parses because mdy() requires slash-separated components.
Explanation: When working with lubridate, the key concept to understand is the difference between format functions and separator sensitivity. Functions like mdy(), dmy(), and ymd() specify the order of date components (month-day-year, in this case), not the separator character used between them. lubridate::mdy() is intentionally flexible — it uses pattern recognition to extract numeric components regardless of whether they're separated by hyphens, slashes, dots, spaces, or other common delimiters. So when you pass "12-01-2024", "12/01/2024", and "12.01.2024" to mdy(), all three are interpreted identically: month = 12, day = 01, year = 2024, producing December 1, 2024 for each. That makes A the correct answer. B is wrong because it assumes mdy() has trouble with dot separators — it doesn't. Lubridate handles dots just as gracefully as hyphens or slashes. C introduces a plausible-sounding but false rule: separators do not determine component order in lubridate. The function name itself (mdy vs dmy vs ymd) encodes the order, not the delimiter. D is the most obviously wrong — mdy() was specifically designed to be separator-agnostic, and requiring slashes would make it nearly useless in real-world data scenarios. A good study tip: whenever you see a lubridate format function, focus entirely on the letter order in the function name to determine parsing behavior, and trust that lubridate will handle messy separators automatically. This separator flexibility is one of lubridate's most practical features.

Question 4

Two systems record the same event using the strings "12 Mar 2024" and "Mar 12 2024". Which pair of calls parses both strings as March 12, 2024?

  1. dmy("12 Mar 2024") and mdy("Mar 12 2024") (correct answer)
  2. mdy("12 Mar 2024") and dmy("Mar 12 2024")
  3. ymd("12 Mar 2024") and ymd("Mar 12 2024")
  4. dmy("12 Mar 2024") and dmy("Mar 12 2024")
Explanation: When working with date-parsing functions in the lubridate package, the function name tells you the expected order of date components in the input string. dmy() expects day-month-year, mdy() expects month-day-year, and ymd() expects year-month-day. Your job is to match each string's actual structure to the correct function. Look at "12 Mar 2024" — it leads with the day (12), followed by the month (Mar), then the year. That's day-month-year order, so dmy() is the right tool. Now look at "Mar 12 2024" — it leads with the month (Mar), followed by the day (12), then the year. That's month-day-year order, making mdy() the correct choice. Choice A correctly pairs dmy("12 Mar 2024") and mdy("Mar 12 2024"), and both return 2024-03-12. Choice B swaps the functions — mdy() applied to "12 Mar 2024" tries to read 12 as a month, which fails or misparsed. Choice C applies ymd() to both strings, but neither string starts with a four-digit year, so lubridate would either throw a warning or return NA. Choice D applies dmy() to both, but "Mar 12 2024" starts with the month, not the day, so dmy() would misinterpret it. A handy memory trick: read the function name as a recipe — whatever order the letters appear is the order your string must follow. Always scan your string left-to-right and ask, "What component comes first?"

Question 5

Assume lubridate is loaded. What is the result of the following expression?

as.integer(mdy("03/01/2024") - ymd("2024-02-28"))

  1. 1, because February ends on the day after February 28
  2. 2, because February 29 occurs between the parsed dates (correct answer)
  3. -2, because the subtraction is evaluated in reverse order
  4. 31, because 03/01/2024 is interpreted as January 3
Explanation: When working with date arithmetic in R's lubridate, you need to think carefully about two things: how each date-parsing function interprets its input string, and what calendar days actually fall between those dates. Here, mdy("03/01/2024") reads the string in month/day/year order, giving you March 1, 2024. Meanwhile, ymd("2024-02-28") gives you February 28, 2024. Subtracting the earlier date from the later one — March 1 minus February 28 — counts the actual calendar days between them. Because 2024 is a leap year, February 29 exists and sits between those two dates. So the difference spans two full days: February 28 → February 29 → March 1. Wrapping in as.integer() converts that difftime object to the plain number 2, confirming B is correct. A is wrong because it claims only one day separates the dates, ignoring that 2024 is a leap year with a February 29. C incorrectly claims the result is negative, but lubridate subtracts the right-hand date from the left-hand date — March 1 minus February 28 is positive. The order is not reversed. D reflects a genuine trap: in base R or ambiguous contexts, 03/01/2024 could be misread, but mdy() is explicit about month-day-year ordering, so it correctly parses to March 1, not January 3. Your study tip: always pair the parsing function name with its letter order — mdy, ymd, dmy — and whenever dates straddle late February in any year, check whether it's a leap year before counting days.

Question 6

What value is assigned to n_missing after this code runs?

dates <- lubridate::ymd(c("2024-02-29", "2023-02-29", "2024-13-01", "2024-12-01")) n_missing <- sum(is.na(dates))

  1. 1, because only the date with month 13 is invalid
  2. 2, because two of the supplied dates are invalid (correct answer)
  3. 3, because only one supplied date is unambiguous
  4. 4, because parsing stops when an invalid date appears
Explanation: When working with date parsing in R, the key question to ask is: which strings represent real calendar dates, and which don't? The lubridate::ymd() function attempts to parse each element independently, returning NA for any string that doesn't correspond to a valid date. Walking through each element: "2024-02-29" is valid because 2024 is a leap year, so February 29 exists. "2023-02-29" is invalid — 2023 is not a leap year, so February 29 never occurred. "2024-13-01" is invalid because month 13 doesn't exist. "2024-12-01" is valid — December 1, 2024 is a real date. So two strings fail parsing, producing two NA values. sum(is.na(dates)) counts those NAs, giving 2 — confirming B is correct. A is wrong because it only accounts for the impossible month (13), ignoring that February 29, 2023 is equally invalid. Leap year validity is a classic trap. C incorrectly claims only one date is unambiguous; in fact, two dates parse successfully. D reflects a misconception borrowed from other parsing contexts — lubridate does not stop at the first failure. It processes every element and returns NA individually for bad entries, leaving valid dates intact. A useful study tip: whenever you see lubridate parsing combined with is.na(), mentally validate each date on two axes — does the month exist, and does the day exist for that specific year? Leap year checks are a favorite trick on R exam questions involving date handling.

Question 7

A legacy system stores dates in year-day-month order. Which expression correctly parses "2024-31-01" as January 31, 2024?

  1. lubridate::ymd("2024-31-01"), treating 31 as the month
  2. lubridate::mdy("2024-31-01"), treating 2024 as the month
  3. lubridate::dmy("2024-31-01"), treating 2024 as the day
  4. lubridate::ydm("2024-31-01"), treating 31 as the day (correct answer)
Explanation: When working with date parsing in R's lubridate package, the key insight is that the function name itself is a format specification — each letter tells R the order of components in your string: year, month, and day. For "2024-31-01", the components appear in year → day → month order, which maps directly to ydm(). This means R reads 2024 as the year, 31 as the day, and 01 as the month — correctly producing January 31, 2024. So D is correct. Here's why each alternative fails: A uses ymd(), which would interpret the string as year=2024, month=31, day=01 — but month 31 doesn't exist, so this throws an error rather than parsing correctly. B uses mdy(), which tries to read 2024 as a month value — also impossible, since months only go up to 12. C uses dmy(), which would treat 2024 as the day component — no calendar has 2024 days in a month, making this another parsing failure. Notice that A, B, and C all describe their own behavior incorrectly in the answer choices, which is a deliberate trap to test whether you truly understand the function naming convention versus just guessing. A handy memory trick: read the function name as a recipe. ydm("2024-31-01") means "the first chunk is the year, the second is the day, the third is the month." Whenever you encounter a non-standard date format, map the positions in your string to the letters in the function name before choosing.

Question 8

Consider the following R code:

x <- c("04/07/2023", "07/04/2023") dates <- lubridate::dmy(x)

Which statement correctly describes dates?

  1. The first date is April 7, and it is earlier than the second date.
  2. The first date is July 4, and it is earlier than the second date.
  3. The second date is April 7, and it is earlier than the first date. (correct answer)
  4. The second date is July 4, and it is earlier than the first date.
Explanation: When working with lubridate date parsing functions, the function name itself tells you the expected format. The function dmy() interprets strings as Day/Month/Year — in that exact order. This is the key insight the question is testing. Applying dmy() to "04/07/2023" reads it as the 4th day of the 7th month (July), giving you July 4, 2023. Applying dmy() to "07/04/2023" reads it as the 7th day of the 4th month (April), giving you April 7, 2023. So the second element of x parses to April 7, and since April 7 comes before July 4 chronologically, the second date is earlier than the first. That makes C the correct answer. Looking at the wrong choices: A incorrectly identifies the first date as April 7 — that's the result of misreading the string using MDY logic instead of DMY. B correctly identifies the first date as July 4 but then claims it's earlier than the second date, which reverses the chronological relationship. D correctly identifies the second date as July 4, but July 4 is later, not earlier, than the first date (also July 4 is actually the first date, not the second — this option confuses both the value and the comparison). As a study tip, always anchor on the function name as a format map: dmy() = Day/Month/Year, mdy() = Month/Day/Year, ymd() = Year/Month/Day. When you see ambiguous date strings like these, that function name is your only reliable clue.

Question 9

What is the most accurate description of the object created by this call?

x <- lubridate::ymd("2024-06-15", tz = "America/New_York")

  1. A Date object for June 15, because ymd() always discards the tz argument
  2. A POSIXct date-time at midnight in the America/New_York time zone (correct answer)
  3. A POSIXct date-time at midnight UTC, regardless of the tz argument
  4. A character string retaining the input text and the supplied time-zone label
Explanation: When working with lubridate's parsing functions, you need to pay close attention to what class of object gets returned — because supplying a tz argument changes the behavior significantly. By default, ymd() returns a Date object, which stores only a calendar date with no time or time zone. However, when you pass a tz argument, lubridate recognizes that you need full date-time precision and upgrades the result to a POSIXct object. The time component is set to midnight (00:00:00), and that midnight is anchored to the specified time zone — in this case, "America/New_York". So B is correct: x is a POSIXct representing midnight on June 15, 2024, in the Eastern time zone. A gets the default behavior right but misses the key exception: ymd() does not discard tz — it uses it as a signal to return POSIXct instead of Date. C describes a real behavior of as.POSIXct() when time zones are mishandled, but lubridate correctly interprets the tz argument as the local time zone for midnight, not UTC — internally POSIXct always stores UTC, but the display and anchor point honor "America/New_York". D is simply wrong; ymd() parses the string into a proper date-time object, it never retains raw character data. A handy rule of thumb: in lubridate, any time tz appears in a ymd()-family call, expect POSIXct back. When tz is absent, expect a plain Date.

Question 10

A set of day-first date labels must be arranged chronologically:

labels <- c("02/03/2024", "15/02/2024", "28/01/2024") result <- labels[order(lubridate::dmy(labels))]

What is stored in result?

  1. c("02/03/2024", "15/02/2024", "28/01/2024")
  2. c("28/01/2024", "02/03/2024", "15/02/2024")
  3. c("15/02/2024", "02/03/2024", "28/01/2024")
  4. c("28/01/2024", "15/02/2024", "02/03/2024") (correct answer)
Explanation: When working with date strings in R, a critical distinction exists between how dates look as text versus how they sort as actual dates. Character sorting treats dates as strings (comparing character by character), which almost never produces correct chronological order. This question tests whether you understand how lubridate::dmy() and order() work together to solve that problem. Here's the logic: dmy(labels) converts each string into a proper Date object — "28/01/2024" becomes January 28, "15/02/2024" becomes February 15, and "02/03/2024" becomes March 2. Then order() returns the index positions that would arrange those parsed dates from earliest to latest: January 28 comes first (index 3), then February 15 (index 2), then March 2 (index 1). Using those indices to subset labels gives you c("28/01/2024", "15/02/2024", "02/03/2024") — the original label strings reordered chronologically. That's D. A is wrong because it's just the original unsorted order — order() was never applied. B is the trap for students who confuse day and month in the dmy format: it places "02/03/2024" second, as if "03" is January or February rather than March. C is completely scrambled and doesn't correspond to any consistent sorting rule — it's a distractor for students who guess. A useful mental habit: whenever you see dmy(), mdy(), or ymd(), always identify which component comes first in your strings and match it to the function name. Then remember that order() returns indices, not values — it's labels[order(...)] that performs the actual reordering.