Introduction

In Swift, converting a Date to milliseconds means converting the timestamp from seconds since the Unix epoch into an integer-like millisecond value. Converting back is the reverse operation: divide milliseconds by 1000 and build a new Date from the resulting seconds.

Convert Date to Milliseconds

Date exposes its Unix timestamp in seconds through timeIntervalSince1970:

1import Foundation
2
3let now = Date()
4let milliseconds = Int64(now.timeIntervalSince1970 * 1000)
5
6print(milliseconds)

timeIntervalSince1970 is a TimeInterval, which is a floating-point number of seconds. Multiplying by 1000 converts seconds to milliseconds, and wrapping in Int64 gives you a convenient whole-number timestamp for storage or transport.

Convert Milliseconds Back to Date

To rebuild the date, divide by 1000.0 so Swift performs floating-point division:

1import Foundation
2
3let milliseconds: Int64 = 1720000000123
4let date = Date(timeIntervalSince1970: TimeInterval(milliseconds) / 1000.0)
5
6print(date)

The 1000.0 matters. If you divide as integers too early, you lose the millisecond fraction.

Wrap the Conversion in Helpers

It is often useful to add tiny helpers so the intent stays obvious:

1import Foundation
2
3extension Date {
4    var millisecondsSince1970: Int64 {
5        Int64((timeIntervalSince1970 * 1000.0).rounded())
6    }
7
8    init(milliseconds: Int64) {
9        self = Date(timeIntervalSince1970: TimeInterval(milliseconds) / 1000.0)
10    }
11}
12
13let createdAt = Date()
14let stored = createdAt.millisecondsSince1970
15let restored = Date(milliseconds: stored)

That keeps conversion code out of business logic and makes serialization code easier to read.

Time Zone Is Not Part of the Stored Timestamp

A Unix timestamp is an absolute moment in time. It does not contain a display time zone. Time zones matter only when formatting the date for humans.

That means these conversions are timezone-neutral. If the displayed clock time looks different across machines, the problem is usually formatting or calendar presentation rather than the timestamp conversion itself.

Choose the Right Numeric Type

Milliseconds can exceed the range of small integer types quickly, so Int64 is a safer choice than Int when the value may be serialized or shared across systems. It is also common in APIs and databases that use millisecond Unix timestamps.

When decoding JSON, check whether the server uses:

• seconds since epoch
• milliseconds since epoch
• an ISO 8601 string instead

Many bugs come from assuming the wrong timestamp unit.

JSON and API Boundaries Are Where Errors Usually Happen

Date conversion bugs often surface when decoding or encoding payloads rather than in the conversion math itself. Make the unit explicit in your models and tests so seconds and milliseconds are never guessed implicitly. That small bit of clarity prevents many hard-to-see production bugs.

Keep Storage and Display Separate

Store timestamps as raw epoch values and only apply formatting when presenting them to a user. That separation keeps serialization code stable and prevents display-specific concerns from leaking into persistence logic.

Common Pitfalls

• Forgetting to multiply by 1000 when converting from Date to milliseconds.
• Dividing milliseconds by 1000 as integer arithmetic and losing the fractional part.
• Confusing milliseconds with seconds in API payloads.
• Blaming time zone differences on the conversion when the real issue is date formatting.
• Using a numeric type that is too small or inconsistent across systems.

Summary

• Use timeIntervalSince1970 * 1000 to convert Date to milliseconds.
• Use Date(timeIntervalSince1970: milliseconds / 1000.0) to convert back.
• 'Int64 is a practical type for storing millisecond timestamps.'
• Unix timestamps represent absolute time, not a time zone.
• Most conversion bugs come from mixing up seconds and milliseconds.