22 comments
@nikitonsky Bespoke multi-layered regex is my guess :) (\s\d{4}) → year eaaaasy 😎 ... wait, what international standards? @ctietze I mean, I get RFC 822, but it’s 'Tue, 3 Jun 2008 11:05:30 GMT' Why would you put year _after_ time zone??? @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, 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. @nikitonsky yes, my bad( > This method is similar to the strftime() function defined in ISO C and POSIX. @nikitonsky Lol. They broke it again. It used to be non-RFC despite the docs a few years ago. Then they fixed it. And now theybroke it again. I can't even imagine *how* you can end up with this format |
@nikitonsky maybe they initially thought Twitter wouldn't last a year and added this later?