Introduction

Despite the title, this question almost always comes up when moving from Java to C#. The closest match to Java System.currentTimeMillis() in modern C# is DateTimeOffset.UtcNow.ToUnixTimeMilliseconds(), because both values represent milliseconds since the Unix epoch in UTC.

What System.currentTimeMillis() Actually Returns

In Java, System.currentTimeMillis() returns wall-clock time, not a high-resolution performance counter. It is useful for timestamps, logging, and coarse scheduling, but it is not the best choice for benchmarking very short code paths.

The equivalent concept in C# is:

1using System;
2
3long currentTimeMillis = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds();
4Console.WriteLine(currentTimeMillis);

This gives you the number of milliseconds elapsed since January 1, 1970 UTC, which is the same basic representation developers usually expect from Java.

Why DateTimeOffset Is The Best Match

You might see older code using DateTime.UtcNow and manual subtraction from the Unix epoch:

1using System;
2
3long currentTimeMillis =
4    (long)(DateTime.UtcNow - new DateTime(1970, 1, 1)).TotalMilliseconds;

That works, but DateTimeOffset.UtcNow.ToUnixTimeMilliseconds() is clearer and avoids mistakes around DateTimeKind.

A safer modern version is:

1using System;
2
3DateTimeOffset now = DateTimeOffset.UtcNow;
4long millis = now.ToUnixTimeMilliseconds();
5Console.WriteLine(millis);

DateTimeOffset represents a real instant in time along with an offset-aware model, which makes it better suited to interoperability than a plain DateTime.

Do Not Use Wall-Clock Time For Benchmarking

If your Java code used System.currentTimeMillis() to measure elapsed duration, the direct C# equivalent is often still the wrong tool. For timing code execution, use Stopwatch:

1using System;
2using System.Diagnostics;
3using System.Threading;
4
5var stopwatch = Stopwatch.StartNew();
6
7Thread.Sleep(150);
8
9stopwatch.Stop();
10Console.WriteLine(stopwatch.ElapsedMilliseconds);

Stopwatch uses a high-resolution timer when available and is much more appropriate for performance measurements.

A useful rule is:

• For timestamps and epoch-based values, use DateTimeOffset.UtcNow.ToUnixTimeMilliseconds().
• For elapsed execution time, use Stopwatch.

Converting Back To A Date

If you receive a Java-style millisecond timestamp and want a readable date in C#, convert it back like this:

1using System;
2
3long millis = 1700000000000;
4DateTimeOffset timestamp = DateTimeOffset.FromUnixTimeMilliseconds(millis);
5
6Console.WriteLine(timestamp);
7Console.WriteLine(timestamp.UtcDateTime);

This is helpful when Java services and C# services exchange epoch timestamps through JSON, Kafka, or REST APIs.

Interoperability Notes

Java and C# both ignore leap seconds in their common Unix-time APIs, so these values are compatible for most application work. The main source of bugs is not the epoch definition but local-time handling around parsing, display, and database storage.

When you serialize timestamps, keep them in UTC or use explicit offsets. Converting to local time too early makes logs and distributed traces harder to compare.

If you need sub-millisecond precision, neither System.currentTimeMillis() nor ToUnixTimeMilliseconds() is enough. Use nanosecond or tick-based APIs only if the receiving systems and storage format can preserve that extra precision.

Common Pitfalls

One common mistake is using DateTime.Now instead of UTC. That gives a local clock reading and introduces time zone and daylight-saving complications when you compare values across systems.

Another pitfall is using wall-clock timestamps for performance measurement. System time can move because of clock adjustments, while Stopwatch is designed for elapsed timing.

Developers also sometimes store epoch milliseconds in a floating-point type. Use long so large timestamps remain exact.

Finally, if the question literally meant the C language rather than C#, this article does not apply. The presence of the C# tags strongly suggests the intended answer is the .NET one shown above.

Summary

• The practical C# equivalent of Java System.currentTimeMillis() is DateTimeOffset.UtcNow.ToUnixTimeMilliseconds().
• Use UTC-based epoch milliseconds for timestamps and cross-language interoperability.
• Prefer DateTimeOffset over manual DateTime epoch math when possible.
• Use Stopwatch, not wall-clock time, to measure elapsed execution duration.
• Store the result in a long and keep time zone handling explicit.