How to Add 1 Day to NSDate: 5 Fatal Mistakes for Beginners in Swift

Introduction: Why Does Your Date Code Work "Intermittently"?

Imagine: you're writing a calendar app or a reminder. You just need to take the current date and add one day to it. Seems simple, right? You open Stack Overflow, find a question with thousands of views "How do I add 1 day to an NSDate?" — and realize that even such a simple operation can turn into a nightmare.

In this article, we'll break down the top mistakes when adding a day to NSDate in Swift, learn how to avoid them, and write correct, reliable code. You'll learn why the old approach with NSDate and timeInterval is a path to bugs, and how modern Apple APIs save the day.

Let's dive into dates once and for all!

Mistake #1: Using timeInterval to Add a Day

Disastrous Code

The most common pitfall beginners step into:

let today = NSDate()\nlet oneDay: TimeInterval = 24 * 60 * 60 // 86,400 seconds\nlet tomorrow = today.addingTimeInterval(oneDay)

At first glance, it's logical. There are 24 hours in a day, 60 minutes in an hour, 60 seconds in a minute. Multiply, add — profit!

But no. This works only in 99% of cases, and in 1% it breaks the entire app for users. Why?

Hidden Pitfalls

\n
• Daylight Saving Time transitions. On the day clocks are changed, a day can last 23 or 25 hours. Your 86,400 seconds will turn into 83,400 or 90,000.
\n
• Leap seconds. Although rare, they officially exist.
\n
• Time zones. If the user is traveling, their local time can get out of sync.
\n
• Second-level precision. You're not just adding "the next day", you're adding exactly 24 hours — these are different things.
\n

Want an example? On March 28, 2021, in Ukraine, clocks were set forward one hour at 3:00 AM. If you added a timeInterval to 2:30 AM, you wouldn't get 3:30, but... 4:30? Or 2:30? It depends on how the system handles the transition. In short, chaos.

Mistake #2: Mixing NSDate and Date in the Same Project

In Swift, there are two date types: the old NSDate (from Objective-C) and the modern Date (Swift-native). Many developers, especially those reading old tutorials or Stack Overflow answers from 2014, continue to use NSDate.

The problem is that NSDate is a class (reference type), while Date is a structure (value type). Mixing them in code leads to:

\n
• Non-obvious bugs with mutability
\n
• Unnecessary conversions (as Date, as NSDate)
• Confusion in APIs

Rule: in new Swift code, use only Date. Leave NSDate for compatibility with Objective-C libraries.

Mistake #3: Ignoring Calendar and TimeZone

When you add "1 day" to a date, you do it in the context of a calendar. Without specifying a calendar, the system uses Calendar.current — the user's calendar (usually Gregorian).

But what if the user from Saudi Arabia uses the Islamic calendar? Or the Japanese one? Without explicitly specifying the calendar, you risk getting unexpected results.

Example of Incorrect Code

var dateComponents = DateComponents()\ndateComponents.day = 1\nlet tomorrow = Calendar.current.date(byAdding: dateComponents, to: Date())

This code is almost correct, but it implicitly uses the device's time zone. If you're working with server dates in UTC, and the user is in Moscow (UTC+3), then "tomorrow" might come 3 hours earlier.

Correct Solution: Calendar + DateComponents

The Gold Standard for Adding a Day

Here's how to correctly add 1 day to