Introduction

To calculate the number of days between two NSDate values in Swift, the safest tool is Calendar, not raw second arithmetic. A "day" in calendar logic is not always exactly 86,400 seconds because time zones and daylight saving changes can shift the clock.

Bridge NSDate to Date and Use Calendar

In modern Swift, Date is the native type, and NSDate bridges to it automatically. To count day boundaries, use Calendar.dateComponents:

1import Foundation
2
3let formatter = DateFormatter()
4formatter.dateFormat = "yyyy-MM-dd"
5formatter.timeZone = TimeZone(secondsFromGMT: 0)
6
7let start = formatter.date(from: "2025-03-01")! as NSDate
8let end = formatter.date(from: "2025-03-07")! as NSDate
9
10let calendar = Calendar.current
11let days = calendar.dateComponents([.day], from: start as Date, to: end as Date).day!
12
13print(days)

This returns 6, which is the number of whole calendar days between those dates.

The key idea is that Calendar understands calendars, locales, and time zones. A raw subtraction does not.

Normalize to Start of Day When You Want Calendar Days

If the two values include times, you may want to compare only their day portion. Normalizing both dates to the start of the day makes that intent explicit:

1import Foundation
2
3let calendar = Calendar.current
4
5let start = Date()
6let end = calendar.date(byAdding: .hour, value: 30, to: start)!
7
8let startDay = calendar.startOfDay(for: start)
9let endDay = calendar.startOfDay(for: end)
10
11let dayCount = calendar.dateComponents([.day], from: startDay, to: endDay).day!
12print(dayCount)

This is often what people really want in apps such as streak counters, booking screens, and deadline logic.

Without normalization, the result represents full elapsed day components between the exact timestamps, which may not match the business rule.

Avoid Dividing Seconds by 86,400

A tempting approach is:

let interval = end.timeIntervalSince(start)
let days = Int(interval / 86400)

That works only for simple elapsed-time calculations and can produce misleading results around daylight saving transitions or when you really mean calendar-day difference.

For example, a date range that crosses a DST jump may have one calendar day between it but not exactly 86,400 elapsed seconds. Calendar handles that correctly because it operates on date components instead of assuming every day is identical in seconds.

Choose the Right Meaning of "Days Between"

There are two common interpretations:

• elapsed 24-hour periods
• calendar day boundaries crossed

If you want elapsed time, timeIntervalSince may be fine. If you want user-facing day counts, scheduling logic, or date-based UI, Calendar is usually the correct choice.

Being explicit about that distinction prevents subtle bugs that only appear in production when users cross time zones or daylight saving changes.

Common Pitfalls

The biggest mistake is dividing a time interval by 86,400 and assuming that always equals calendar days. It does not.

Another issue is mixing time zones unintentionally. If one date formatter uses UTC and another uses the local time zone, the resulting day count can shift by one unexpectedly.

Developers also often forget that NSDate and Date bridge freely in Swift. You do not need a separate legacy-only approach just because the variable type started as NSDate.

Finally, clarify whether the app wants whole elapsed days or day-boundary difference. Those are related, but not always identical.

Summary

• Use Calendar.dateComponents([.day], from:to:) for day differences in Swift.
• 'NSDate can be bridged to Date directly.'
• Normalize to startOfDay when the business rule is based on calendar days.
• Avoid raw seconds / 86400 for user-facing date logic.
• Time zones and daylight saving changes are the reason Calendar is the safer default.