Introduction

Adding one month to an NSDate is not the same as adding thirty days. Calendar months have different lengths, so the correct approach is to use Calendar and date components rather than raw second arithmetic.

Prefer Date and Calendar

In modern Swift, Date is the idiomatic type and bridges automatically to NSDate. To add one month, use Calendar.date(byAdding:value:to:):

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

If you already have an NSDate, bridge it:

1import Foundation
2
3let nsDate = NSDate()
4let swiftDate = nsDate as Date
5
6if let nextMonth = Calendar.current.date(byAdding: .month, value: 1, to: swiftDate) {
7    print(nextMonth as NSDate)
8}

This is the correct calendar-aware solution. It respects month boundaries instead of pretending every month has a fixed duration.

Why Not Add Seconds Manually

A month is not a fixed number of seconds. Adding 30 * 24 * 60 * 60 can give the wrong result for:

• February
• months with 31 days
• daylight saving time transitions

That is why Foundation provides calendar-based arithmetic. Dates represent points in time. Calendars define how humans interpret those points as months, days, and years.

Month-End Behavior Matters

Consider January 31 plus one month. What should the result be? Calendar arithmetic resolves that using the calendar’s rules:

1import Foundation
2
3let formatter = DateFormatter()
4formatter.dateFormat = "yyyy-MM-dd"
5
6let date = formatter.date(from: "2025-01-31")!
7let nextMonth = Calendar.current.date(byAdding: .month, value: 1, to: date)!
8
9print(formatter.string(from: nextMonth))

The result will land on the last valid day in the target month according to Foundation’s calendar behavior. That is almost always what you want for business and UI logic.

Use a Specific Calendar and Time Zone When Precision Matters

Calendar.current reflects the user’s current locale and time zone. That is fine for many app features, but for repeatable behavior, use an explicit calendar and time zone:

1import Foundation
2
3var calendar = Calendar(identifier: .gregorian)
4calendar.timeZone = TimeZone(identifier: "UTC")!
5
6let formatter = DateFormatter()
7formatter.calendar = calendar
8formatter.timeZone = calendar.timeZone
9formatter.dateFormat = "yyyy-MM-dd HH:mm:ss"
10
11let date = formatter.date(from: "2025-03-31 12:00:00")!
12let result = calendar.date(byAdding: .month, value: 1, to: date)!
13
14print(formatter.string(from: result))

This is a better choice for tests, server-aligned logic, and anything where a user’s local settings should not change the result.

Add Multiple Components Safely

If you need more than one date change, use DateComponents:

1import Foundation
2
3let date = Date()
4var components = DateComponents()
5components.month = 1
6components.day = 3
7
8if let result = Calendar.current.date(byAdding: components, to: date) {
9    print(result)
10}

This keeps the operation declarative and calendar-aware.

Use Calendar Math for Recurring Rules

This matters most in recurring features such as billing cycles, subscriptions, or reminder dates. Those features usually care about “same day next month” rather than “thirty days later”. Calendar expresses that intent directly, which makes the code easier to review and much less fragile.

Common Pitfalls

• Treating a month as a fixed number of days or seconds.
• Doing date math with raw timestamps when the real problem is calendar arithmetic.
• Forgetting that NSDate and Date bridge cleanly, then writing unnecessary conversion code.
• Ignoring time zone and locale when consistent results matter across devices or tests.
• Being surprised by end-of-month behavior without deciding what the business rule should be.

Summary

• Add one month with Calendar.date(byAdding: .month, value: 1, to: ...).
• Prefer calendar arithmetic over manual second arithmetic.
• Bridge NSDate to Date and back when needed instead of using older APIs directly.
• Be explicit about calendar and time zone when deterministic behavior matters.
• Test end-of-month cases because they are where date logic usually breaks.