Email or username:

Password:

Forgot your password?
Top-level
Григорий Клюшников

(btw Mastodon API and ActivityPub also use strings for timestamps)

10 comments
Niki Tonsky

@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

Григорий Клюшников

Niki, unixtime, of course. A string can be malformed. A number can not, not without making the entire JSON invalid.

iliazeus

@grishka ...but do you mean _true_ unixtime (i.e. in seconds), or Java/JavaScript "unixtime" (i.e. in milliseconds)?

@nikitonsky

Григорий Клюшников

iliazeus, in most cases, true unixtime as a 64-bit integer. You usually don't need millisecond precision.

iliazeus

@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.

@nikitonsky

Григорий Клюшников

iliazeus, at least PHP's time() returns unixtime in seconds so there are examples of both.

iliazeus

@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.

@nikitonsky

Григорий Клюшников

iliazeus, iirc it's also popular in binary file formats to store timestamps as unixtime in seconds.

Niki Tonsky

@grishka why would string be malformed but number wouldn’t?

Go Up