Timestamp Converter

How to convert a Unix timestamp to a date online

1. Click Use current time to pre-fill with the live Unix timestamp.
2. Enter a Unix timestamp (seconds or milliseconds) to see the equivalent date in ISO 8601 and other formats.
3. Enter an ISO 8601 date string to get the equivalent Unix timestamp.
4. Click Convert to see the result.

DateTime bugs in .NET: the ones that make it to production

I have seen more bugs caused by DateTime vs DateTimeOffset confusion than by almost any other type in .NET. The root cause is always the same: DateTime.Now captures local server time, not UTC, and when that value gets stored in a database or compared against an external system's timestamp, it's off by the server's UTC offset — silently, with no compile-time warning. The fix is to use DateTimeOffset.UtcNow everywhere and store UTC timestamps in your database columns.

DateTime vs DateTimeOffset vs Unix timestamps in .NET

The three representations of time in .NET each have distinct roles:

• DateTime — stores a date and time with a Kind property (Utc, Local, or Unspecified). The Unspecified kind is the dangerous default — it has no timezone information, so comparing two Unspecified DateTime values that came from different timezones produces wrong results without any error.
• DateTimeOffset — stores a date, time, and an explicit UTC offset. This is the recommended type for all new code. It cannot be accidentally "local" — the offset is always explicit, and comparison is always by UTC value.
• Unix timestamp (long) — an integer count of seconds (or milliseconds) since the Unix epoch (1 Jan 1970 UTC). This is the universal language between systems: SQL databases, JavaScript APIs, JWT exp claims, Redis TTLs, and log systems all speak Unix timestamps.

// Convert to/from Unix timestamps in .NET
DateTimeOffset now = DateTimeOffset.UtcNow;

// DateTimeOffset to Unix seconds
long unixSeconds = now.ToUnixTimeSeconds();

// DateTimeOffset to Unix milliseconds
long unixMs = now.ToUnixTimeMilliseconds();

// Unix seconds back to DateTimeOffset
DateTimeOffset fromSeconds = DateTimeOffset.FromUnixTimeSeconds(unixSeconds);

// Unix milliseconds back to DateTimeOffset
DateTimeOffset fromMs = DateTimeOffset.FromUnixTimeMilliseconds(unixMs);

// Format as ISO 8601 for JSON APIs and log output
string iso = now.ToString("yyyy-MM-ddTHH:mm:ssZ");

// EF Core: map a column as Unix timestamp (store as long in SQL)
// In your entity configuration:
// builder.Property(e => e.CreatedAt)
//     .HasConversion(v => v.ToUnixTimeSeconds(),
//                    v => DateTimeOffset.FromUnixTimeSeconds(v));

Seconds vs milliseconds — the most common confusion

Treating a millisecond timestamp as seconds gives you a date in the year 57,000. Treating a seconds timestamp as milliseconds gives you a date in early January 1970. Both are common bugs. If an API timestamp looks obviously wrong, this converter is the fastest way to check which unit it's in.

Five real .NET use cases

1. Debugging a JWT exp or iat claim value. JWT timestamps are always Unix seconds. Paste the numeric value here to see whether the token is expired, when it was issued, and how far the nbf (not before) window extends.
2. Checking whether an EF Core timestamp column is storing local or UTC time. Query the raw value from the database, paste it here, and compare the displayed UTC time against what you expected. A timezone offset error shows up immediately as an off-by-N-hours discrepancy.
3. Converting a Redis TTL or cache expiry to a human-readable time for debugging. Redis stores expiry as Unix seconds. EXPIRETIME mykey returns a raw integer — paste it here to see when the cached value expires.
4. Validating a webhook timestamp from Stripe, Twilio, or GitHub to check for replay attacks. These platforms include a timestamp in the signature payload. Convert the timestamp to local time to verify the request is recent (typically within 5 minutes).
5. Understanding a log entry's epoch timestamp from Azure Application Insights, Datadog, or Elasticsearch. Structured logging often includes a Unix millisecond timestamp field. Paste the raw value here to see the human-readable time without running a query.

Frequently asked questions

Should I use DateTime or DateTimeOffset in ASP.NET Core? Use DateTimeOffset for all new code. DateTime with Kind = Unspecified is the source of the majority of timezone-related bugs in .NET applications. DateTimeOffset always carries explicit offset information and compares by UTC value, making timezone-related bugs much harder to introduce.

Why does EF Core sometimes store my DateTimeOffset as local time in SQL Server? SQL Server's datetime2 column type does not store timezone offset. EF Core stores the UTC value for DateTimeOffset properties but strips the offset. Use datetimeoffset as the column type (HasColumnType("datetimeoffset") in configuration) if you need to preserve the original offset in the database.

The Year 2038 problem — does it affect .NET? No. .NET's DateTime and DateTimeOffset use 64-bit internal representations, not 32-bit integers. The Y2K38 problem only affects systems (typically embedded or legacy C code) that store timestamps as 32-bit signed integers. Check your SQL database column types if you have old schema that predates 64-bit timestamp columns.

ISO 8601 — the unambiguous text format for APIs

ISO 8601 represents dates and times as YYYY-MM-DDTHH:mm:ssZ (UTC) or YYYY-MM-DDTHH:mm:ss+HH:mm (with offset). ISO 8601 strings sort correctly as plain strings, are locale-independent, and are the recommended format for all date values in JSON APIs and log files. In .NET, DateTimeOffset.ToString("o") produces round-trippable ISO 8601 with full offset information.