Why #Ao3 was down yesterday:

@vashti and this is why we shouldn't store numbers in fixed width fields, or compute using 32 or 64 or 128 bit or any other fixed size integers.

Bignum arithmetic has been a solved problem in computing since Maclisp in the 1960s.

#Lisp

@simon_brooke @vashti I assume it's using SQL for the database. Does SQL even have a variable width datatype for numbers?

@Rusty @vashti strictly speaking, no, although some databases can store extremely large numbers.

https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL

@simon_brooke @vashti Yeah, AO3 is pretty old though so I'd imagine it would make sense to just use the standard int for the table ID since why waste the resources to make it a bigint? Surely we'll never cross 2 billion. ​

@vashti

Yeah, I would use a 64-bit ID or UUID for anything that users can generate a lot of. 2 or 4 billion is a lot, but it's well within the ability of all humankind to reach it. See also: IPv4 addresses.

exhibit 13872137129712984 as to why 32 bit is a bad size for a numeric type

RE: https://hachyderm.io/@vashti/114796178488509837

@charlotte oh you think you’re smart until someone just has to bookmark 13 quadrillion fics and the 64-bit index overflows too

use my 128 bit ID type that’ll let you make 281,474,976,710,656 bookmarks per nanosecond for about a million years

@eri there’s even an UUID version which only lets you do so for 300,000 years

@charlotte ferb, i know what we’re going to do for the next million years

@simon_brooke @vashti 2⁶⁴ microseconds is approximately 580 000 years (more than that, rounding down), so 2⁶⁴ is more than plenty

@catgirlQueer @vashti As I myself wrote, years ago,

"At nanosecond resolution (if I've done my arithmetic right), 128 bits will represent a span of 1 x 10²² years, or much longer than from the big bang to the estimated date of fuel exhaustion of all stars. So I think I'll arbitrarily set an epoch 14Bn years before the UNIX epoch and go with that. The time will be unsigned - there is no time before the big bang."

So, yes, if you're content with nanosecond resolution...

https://github.com/simon-brooke/post-scarcity/wiki/cons-space#time

@simon_brooke @catgirlQueer @vashti

Fun fact:

Until 1972-01-01Z we used rubber-time, because astrometry is not nearly as constant as most people seem to think.

But it is worse than that.

We literally have no idea how long nanoseconds took before 1958-01-01Z

If you go back before observations of solar eclipses, we even barely know how long days took.

Any epoch before 1972-01-01Z by defintion causes wrong timekeeping.

@simon_brooke @catgirlQueer @vashti

Also:

Until we ditch leap-seconds, we cannot predict how many seconds there will be until some timestamp in the future, since that depends on what the director of the Paris Observatory decides twice a year.

And on top of that, time-zones are political decisions, so even without leap-seconds, it is anyone's guess how long time there is to 2026-01-01 09:00 in Mississippi.

@simon_brooke @catgirlQueer @vashti

So there is no "fix it once and for all" solution to timekeeping, and the best and most robust strategy will always be store timestamps the way the user provided them, and interpret them as best you can, given the knowledge available to you, when you do.

@simon_brooke @catgirlQueer @vashti

And as for nanosecond resolution: Now you also need to think about which relativistic reference frame to use.

@bsdphk @simon_brooke @vashti I thought leap seconds are excluded from Unix time. So we know many Unix seconds it is until a certain date, but we don’t know how long a Unix second is (currently it’s around 1 real second or a little bit more, but it will fluctuate over time)

@jornane @simon_brooke @vashti

That is a slightly less precise way to say the same thing.

@bsdphk @catgirlQueer @vashti Rubber time in this sense?

https://medium.com/know-thyself-heal-thyself/jam-karet-rubber-time-6776fba793a

@simon_brooke @catgirlQueer @vashti

No, rubber time in the sense of "I know the two timestamps, but I do know how long time there was/is/will be between them.

Timestamps and time-scales are merely labels we stick on time to the best of our ability, they are not actually time.

@bsdphk @catgirlQueer @vashti so a canonical ordering of events, without precise periods between them?

@simon_brooke @catgirlQueer @vashti

Ordering is an entirely different issue.

@bsdphk @catgirlQueer @vashti ok, now I'm not understanding. When you say "you know of two different timestamps", do you know which (within a locality) preceded the other? Or do they simply float in an unordered soup?

@simon_brooke @catgirlQueer @vashti

What I'm trying to say is that timestamps are conventions, what they mean depends entirely on the convention, and conventions change over time and space.

From 1958 to 1972 the UTC timescale used SI-seconds, but we adjusted the lengths of those SI-seconds to match the erratic rotation of the planet.

So if you define a timescale based on SI-seconds and extend it back in time, what does that mean ?

@simon_brooke @catgirlQueer @vashti

It literally means that the years 1973 and 1967 did not have the same duration.

So what is your timescale measuring ?

The physical duration we barely have measurements to know precisely ?

Or the conventional difference between the timestamps, disregarding physical reality ?

Talking about nanosecond timescales prior to 1958 simply makes no sense.

@bsdphk @catgirlQueer @vashti like any other human measurement, it's arbitrary. Is the kilogram of platinum carefully stored in Paris getting heavier or lighter? Is the new definition, based on Planck's constant, more durable? We're used to measuring with arbitrary scales.

I think.

Don't you?

@simon_brooke @catgirlQueer @vashti

They all important difference is that we could pull the meter or the kilogram out of the vault and measure them as often as we want, with increasingly sophisticated methods.

When measuring time we get only one chance, in real time, to measure the duration of any specific time-interval.

There can be no "do-over", no "try again with a better clock" and no "best out of N".

@simon_brooke @catgirlQueer @vashti

But time is still different, because it is a real-time running accumulation of non-repeatable measurements of duration.