What are all the known serialization formats of (unix) epoch time?

Question

So, the basic definition of epoch time (similar to 'unix time', but not exactly: see below) and what it means is clear. However, nowhere on the wikipedia page or on any other resource I can find is it mentioned that epoch time can be serialized (ie. to JSON, CSV, XML, etc.) in various equally-modern formats with varying degrees of precision. Which is not a shock, right? Different programming languages do things in different ways. That's a given. But, the semi-consistent usage of epoch time itself across so many languages could possibly indicate one of two things:

1. an actual standard/spec, albeit a weak one with gaps
2. an informal convention-by-mistake, about which: assume nothing

(Note: I am NOT asking about ISO formatted date/time strings and the variants of those. Separate topic. Further, I'm not talking about low-level programming representations of these numbers, like signed vs. unsigned integers, 32 vs 64 bit, leap-seconds vs none, etc. Wikipedia actually covers all that. Just the various serializations of the epoch/unix time, ie. in a console, in JSON, in a database, etc.)

For instance, I've stumbled across at least 3 basic variants:

• 1707882022 - In seconds
• 1707882022000 - In milliseconds (no decimal indicator)
• 1707882022.159835 - In seconds, with decimal indicator and (up to) microsecond precision

Javascript, for instance, defaults to the milliseconds option, while Python 3 defaults to seconds with microsecond precision.

My question is: is that all the known options/formats? And, is there any common specification/definition of them, or is it all just ad-hoc decisions by language designers, and so you just need to read the specs for all of them, separately?

Bonus question: I know that translating between simple mathematical units like these is the appropriate work of programmers. But, as the life of senior programmers involves bringing junior people up to speed on such questions: are there any particular tools which specialize in transparent and ergonomical translation between these particular formats, or is it too seemingly simple/fundamental for anyone to have bothered? (I'll note that it's only simple if you already know what all the possibilities are, and how to recognize them. For which: there's seemingly no guide. And no clear reason why not.)

UPDATE: Some specs, such as IETF RFC-7493, have attempted to reckon with this question, and to establish a level playing-field for serialization, although they don't help in documenting the current, fragmented state of play.

UPDATE: We have usefully clarified that "Unix time" and "Epoch Time" are not the same things. I don't know if it's formally specified anywhere, but (at least according to Wikipedia) "Unix (System) Time" is always counted in seconds. Whereas, the more general concept of "(Unix) Epoch Time" simply means time since Jan 1, 1970, which is counted by different programming languages in either seconds or milliseconds, at varying levels of precision. So, for the sake of clarity, I've edited my question to be about (Unix) Epoch Time, not Unix Time.

UPDATE: one poster has suggested that DateTime objects serialized directly to JSON are inherently numbers, not strings. Some serialization implementations do indeed behave that way, so we might go so far as to say that it's an unwritten convention. However, it's unfortunately not part of the JSON spec. And, because JSON payloads are often assembled via intermediate stages, it's quite common to have an end-product batch of JSON that doesn't come directly from system DateTime objects, but may have been processed/calculated, or de-/re-serialized somewhere in the pipeline, into another format. For instance, I've got a junior data scientist working in Python who has somehow managed to serialize a datestamp to JSON with 7 digits of decimal precision, rather than the conventional 6. He has no idea how/where it happened, and nothing in his toolchain coerced it to a more conventional value.

Answer 1

No, these values aren't magically interoperable. 1707882022 may be Feb 14 2024 as seconds, or Jan 20 1970 as milliseconds. No system can detect which is correct. You need to read the documentation of the relevant systems, which will hopefully tell you whether seconds or milliseconds are used, and whether they use floats or ints. Other systems may also make up additional formats as they please if it makes sense. You'll need to convert between the formats as necessary, which mostly means dividing or multiplying by 1000 as necessary and perhaps casting to float or int.

If you're working with lower level languages, you'd even need to consider whether to use a 32bit int, a 64bit int, or a float type. It's always a case-by-case decision.

---

You're trying to look for some magic which cannot exist. If you have understood the above point about Feb 14 vs Jan 20, then it's clear there's absolutely no way to know from a plain number itself what it represents. Since you'll be encountering these numbers in the wild, you will simply have to study the accompanying documentation. End of story.

If this is too ambiguous for your own taste, then use ISO 8601 datetimes to express your times instead of Epoch time whenever you're in control. This is another format to express timestamps, and it solves all the issues you're worrying about. You don't need to fix Epoch times, you can just use another format entirely.