Hacker News Reader

Comment by userbinator | Hacker News Reader

Dates were represented as strings in "YYYYMMDD" format (so today would be "20210113053923") instead of UNIX timestamps

Such a representation naturally avoids the Y2K38 problem, and could go beyond Y10K. It's traditional in Windows and DOS (neither of which have the Y2K38 problem) to store timestamps as a structure of fields.

The other things you noted I agree with, however.

View on HN

If they're using a javascript 53bit int representation for the seconds (or an int64_t cast down to a javascript big int) then it's a Y142711K problem, by which point the Imperium of Mankind will hopefully have settled on a more robust format.

The tech-priests will have lost the ability to fix it.

That's how we ended up with the 2038 problem!

I expect Slaanesh and friends will manage to sabotage that somehow.

You can also instantly read them which makes troubleshooting easier. I mean sure, if your shit is too slow maybe switch to less text in release mode but YAGNI.

Well, assuming they're storing the strings as ASCII, that's 98 bits - the y2k38 problem is for 32 bit integers, so a 64 bit integer would be way, way more than needed for human needs for foreseeable generations.

Doesn't seem to me like Parler will have to worry about Y2K38...

A timestamp is a timestamp. It isn't a date. If you need a date, use a proper date/time data type.

All timestamps have to start somewhere. If you want to avoid DST changes and leap seconds, you can use MJD, TAI or GPS time instead of UTC, but you might as well format it nicely so that you can see roughly at what (civil) date something happened.

ISO 8601 is a good one.

Nice that makes sense. I was unaware and found it strange when I plugged it into JavaScript's Date constructor and got an "Invalid Date" error.

This.

Plus, it's unambiguously human readable, for users, bystanders, platform developers, everyone. There's a useful usability principle in there.

Reply on news.ycombinator.com