Always good in these kind of time-related situations to dig up https://news.ycombinator.com/item?id=4128208 which links to "Falsehoods programmers believe about Time": https://infiniteundo.com/post/25326999628/falsehoods-program...
This itself is a falsehood, at least as such a strong statement. You'll avoid some of the falsehoods in the text, but as long as humans and politics exists you also need to consider timezones and leap seconds and make a concious decision on when to apply and when to avoid them.
The leap seconds and other sludge can be compensated for when converting on-the-fly to a human readable format. That's one of the strengths of this system - it pushes the issues of politics up to the client, where those issues belong.
I'm curious, what does the "number of milliseconds since" do, then? If it's about intervals, and it has some human connection, you're still in political land (and not only on the client) if you do something like: 3am, 1 month from today 3am.
An offset from a known epoch has no dependency on any calendar-based time representation. Regardless of whether you call it 1 January 1970 00:00:00 or January 1 1970 12:00:00 AM, we can agree that that's a point in time that exists, and we can count the number of (seconds|milliseconds|whatever) since that instant and get the same result.
More concisely, an offset from a known epoch has no dependency on how many days are in a month, or seconds are in a minute, or how many nanoseconds are in a second, etc.
An offset from a known epoch is only trivially dependent on the length of any particular time unit. Need to convert a classic UNIX time to milliseconds? Multiply it by 1000. Did the governing bodies of the world decide to change seconds to be 5% longer? Divide by 1.05 before showing a value to the user.
Offsets from a known epoch makes it quite easy to perform important tasks like clock drift compensation, even wirelessly on teeny microcontrollers with a couple microamps of power. Ask me how I know.
When you deliver a client a time represented as an offset from a well-known epoch, you allow the client (and, thus, the user) to decide how the time should be represented. This improves readability an accessibility with less complexity than would be necessary to convert a calendar-based time format. Reduced complexity leads to reduced computational overhead and fewer opportunities for bugs to pop up.
Determining the epoch itself is non-trivial unless you use one that's already in widespread use. Thankfully, there are a few of those to choose from, like the UNIX epoch or Windows NT epoch. Some industries even have their own de facto standards [1]. But once you've picked an epoch, you have a system that's virtually maintenance-free until the integer saturates. Make the integer wide enough, and you can hope that computers will natively support larger integers by that point, making upgrades trivial. Or, make it so big that all of humanity will have been vaporised and the issue will be moot. In any case, you'll have a time representation that's more efficient and more maintainable than anything calendar-based.
[1]: https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc...