Gregory's Server(btw Mastodon API and ActivityPub also use strings for timestamps)
|
10 comments
 Niki, unixtime, of course. A string can be malformed. A number can not, not without making the entire JSON invalid.  iliazeus, in most cases, true unixtime as a 64-bit integer. You usually don't need millisecond precision. @grishka so you're going against default conventions both in JVM (new Date(ms) and date.getTime()) and in JS (new Date(ms) and date.valueOf())? (possibly somewhere else, idk) What I'm saying is, if picking a number-based timestamp format, I'd pick unixtime in milliseconds. I thing it would be the least surprising option. iliazeus, at least PHP's time() returns unixtime in seconds so there are examples of both. @grishka well, PHP's stdlib was basically starting as thin wrappers over C stdlib functions. Python also has it in seconds, but it does this weird thing where its timestamps are floating-point. C# seems to use 100-microsecond "ticks". Go uses nanoseconds, iirc. So yeah, it's even more ambiguous. If I have a choice, I usually prefer ISO 8601 strings myself. They're standard, unambiguous, human-readable, and even sortable as strings. iliazeus, iirc it's also popular in binary file formats to store timestamps as unixtime in seconds.   |
@grishka I don’t mind the string (what else would you use?) but the format itself. It resembles RFC 822, but year is for some reason _after_ time zone