Introduction

To add one calendar day to an NSDate, use Calendar or NSCalendar, not raw second arithmetic. Adding 86400 seconds looks tempting, but it can be wrong around daylight saving time transitions and calendar boundaries. Date arithmetic should be calendar-aware.

The Modern Swift Approach

In Swift, the modern type is Date, which bridges with NSDate. The usual solution is Calendar.current.date(byAdding:value:to:).

1import Foundation
2
3let today = Date()
4let calendar = Calendar.current
5
6if let tomorrow = calendar.date(byAdding: .day, value: 1, to: today) {
7    print(tomorrow)
8}

This asks the calendar to add one day as a calendar component, which is exactly what you want for user-facing date logic.

Why Not Add 86400 Seconds?

A day is not always exactly 86400 seconds in local calendar terms. Daylight saving time changes can create shorter or longer local days.

This approach is risky:

let tomorrow = today.addingTimeInterval(86400)

It adds a fixed amount of elapsed time, not a calendar day. If the user's timezone crosses a DST boundary between the two dates, the local clock result may be off by an hour relative to the intended calendar date.

For timers and elapsed durations, fixed seconds can be correct. For "tomorrow" in calendar logic, use Calendar.

Working with NSDate

If your code still uses NSDate, the same idea applies because Swift bridges NSDate and Date.

1import Foundation
2
3let today: NSDate = NSDate()
4let calendar = Calendar.current
5
6if let tomorrow = calendar.date(byAdding: .day, value: 1, to: today as Date) {
7    let nsTomorrow = tomorrow as NSDate
8    print(nsTomorrow)
9}

This is common in older codebases that still expose Objective-C APIs or legacy Foundation types.

Objective-C Style with NSCalendar

In Objective-C or older Foundation code, use NSCalendar and NSDateComponents.

1NSDate *today = [NSDate date];
2NSCalendar *calendar = [NSCalendar currentCalendar];
3NSDateComponents *components = [[NSDateComponents alloc] init];
4components.day = 1;
5
6NSDate *tomorrow = [calendar dateByAddingComponents:components
7                                             toDate:today
8                                            options:0];

This is the same idea in older API style: add one calendar day, not a fixed second offset.

Time Zones and User Expectations

Calendar arithmetic depends on the calendar and timezone in use. That is usually what you want, because the user expects "add one day" to follow their local calendar.

If your logic must use a specific timezone, configure the calendar explicitly.

1import Foundation
2
3var calendar = Calendar(identifier: .gregorian)
4calendar.timeZone = TimeZone(identifier: "UTC")!
5
6let now = Date()
7if let nextDay = calendar.date(byAdding: .day, value: 1, to: now) {
8    print(nextDay)
9}

This matters in server code, synchronization logic, and apps where date calculations must be consistent across regions rather than tied to the current user settings.

Start-of-Day Logic Is a Different Requirement

Sometimes "add one day" really means "move to the next calendar day at midnight." That is a slightly different operation.

1import Foundation
2
3let calendar = Calendar.current
4let today = Date()
5
6if let tomorrow = calendar.date(byAdding: .day, value: 1, to: today) {
7    let tomorrowStart = calendar.startOfDay(for: tomorrow)
8    print(tomorrowStart)
9}

If you skip that distinction, it is easy to accidentally preserve the original time-of-day when the actual requirement was "next day at the beginning of the day."

Common Pitfalls

The most common mistake is adding 86400 seconds and assuming that means "one day" in every calendar context. Another is forgetting which timezone the calculation should use, especially in apps that mix user-local display logic with server or UTC logic. Developers also sometimes work with NSDate in older code and forget that the recommended arithmetic still belongs in Calendar or NSCalendar, not in the date object itself.

Summary

• Add one day with Calendar.date(byAdding:value:to:) or the Objective-C NSCalendar equivalent.
• Do not use 86400 seconds for user-facing calendar logic.
• 'Date is the modern Swift type, but the same approach works with bridged NSDate.'
• Set the calendar timezone explicitly when business rules require it.
• If you need the next day at midnight, combine day addition with startOfDay.