Dates and Times Drills: 15 R Problems That Trip Everyone Up

Explanation: as.Date() cannot guess that 15/03/2024 is day-first, so without the format argument it either returns NA or silently misreads the day as a month. The strptime tokens %d, %m, and %Y spell out the exact layout. When a column mixes separators or orders, this is where parsing quietly goes wrong, so always state the format explicitly for anything that is not ISO year-month-day.

Explanation: Writing a format string for "March 15, 2024" is fiddly because of the comma and the full month name. lubridate's mdy() reads the order you name (month, day, year) and tolerates the punctuation, returning a clean Date. The sibling helpers ymd(), dmy(), and their _hms variants cover the other common orders. The one rule that trips people is that you still choose the order; lubridate does not detect it for you.

Explanation: parse_date_time() tries each order in turn and keeps the first that succeeds for every element, which is exactly what a column of inconsistent formats needs. Here the ISO, slash, and month-name strings all resolve to the same date. It returns POSIXct in UTC, so wrap the result with as.Date() if you only want the calendar date. A common mistake is forgetting that a genuinely unparseable value becomes NA with a warning rather than stopping with an error.

Explanation: format() turns a Date into text using strptime tokens: %b is the abbreviated month, %d the zero-padded day, and %Y the four-digit year. The output is a character string, no longer a Date, so do any formatting last, after all sorting and arithmetic. Month and weekday names follow the session locale, so %b prints "Mar" in an English locale but something else elsewhere; set the locale explicitly if a report must be language-stable.

Explanation: quarter() maps any date to 1 through 4, and year() pulls the calendar year, so pasting them builds a compact grouping key. Because the result is character, it sorts alphabetically, which happens to match chronological order only while the years stay four digits and the quarter stays a single digit. For grouping that is usually enough, but for axis labels prefer a factor with explicit level order so the sort is guaranteed correct.

Explanation: difftime() returns a special object that carries its unit, so printing it shows "Time difference of 52.14286 weeks" rather than a bare number. Subtracting two Dates gives the same thing in days by default, so the units argument is what lets you ask for weeks, hours, or minutes directly. To use the value in later arithmetic, strip the wrapper with as.numeric(), which also lets you pin the unit in a single step.

Explanation: Dividing elapsed days by 365.25 ignores leap years unevenly and can push someone to the wrong age right around their birthday. Building an interval and taking integer division by years(1) counts only fully completed years, which is what legal and KYC definitions of age actually mean. Because 2024-03-15 falls before the June birthday, the answer is 33, not 34. The same %/% trick works with months(1) or weeks(1) for other completed-unit counts.

Explanation: Enumerating every day with seq() and testing wday() is the dependable way to count business days, because wday() returns 1 for Sunday through 7 for Saturday regardless of locale, unlike the text from weekdays(). Excluding positions 1 and 7 leaves the weekdays, giving 21 for March 2024. This does not remove public holidays; for that, also subtract a known holiday vector, which is how most real business-day calendars are built.

Explanation: seq() with by = "month" steps one month at a time and lands on the same day-of-month as the start, so beginning on the first keeps every result on a first. Pasting strings like "2024-", the month, and "-01" looks simpler but breaks the moment you need to filter or iterate, because the values stay character. A real Date sequence sorts, compares, and joins correctly, which is worth the extra call.

Explanation: cut() with breaks = "quarter" assigns each date to the quarter it falls in and labels the bin with that quarter's first day, so wrapping it in table() gives counts per quarter. The labels are an ordered factor, which keeps the columns in calendar order even when the data is shuffled. The shortcuts "month", "week", and "year" work the same way, and you can pass explicit break dates for custom periods such as fiscal quarters.

Explanation: ceiling_date() snaps a date up to the start of the next month, and subtracting one day lands on the true month end, so February resolves to the 29th in the leap year 2024 with no special case. Hard-coding 28, 30, or 31 is the classic bug this avoids. The mirror operation, floor_date(), snaps down to the first of the month, and together they bracket any billing or reporting period cleanly.

Explanation: force_tz() keeps the clock reading and changes only the label, which is how you fix a timestamp tagged with the wrong zone. with_tz() does the opposite: it keeps the same physical instant and re-expresses it in another zone, so the clock changes. Confusing the two is the single most common time zone bug. Here the corrected New York 09:00 becomes 13:00 UTC, because mid-March is already on daylight time at four hours behind UTC.

Explanation: with_tz() never changes the underlying instant; it only changes how that instant is displayed, so one moment reads as different wall-clock times in different cities. Tokyo, nine hours ahead, is already on the next calendar day, while Los Angeles in June is on daylight time at seven hours behind. Storing timestamps in UTC and converting only for display is the discipline that keeps this correct, and formatting to text should always be the last step.

Explanation: Because the local clock skips from 02:00 to 03:00 on the spring-forward night, 02:30 is not a real instant, and lubridate returns NA with a "failed to parse" warning rather than inventing a value. Code that assumes parsing always succeeds will silently propagate that NA into everything downstream. The defensive move is to store and construct timestamps in UTC, where no gaps or repeats exist, and convert to local time only for display.

Explanation: A period like days(1) is calendar arithmetic: it advances the wall clock to the same time the next day, so noon stays noon even though only 23 real hours passed across the spring-forward. A duration like ddays(1) is exactly 86400 seconds of physical time, so it lands an hour later on the clock. Reach for periods when humans care about the clock reading, and durations when you need true elapsed time.