There are various objections to expanding the conventional, up-tight, as-God-intended "one man, one woman" notion of marriage but by far the least plainly bigoted ones I am aware of are the bureaucratic ones.
To be blunt, the systems aren't set up to handle it. The paper forms have a space for the husband's name and a space for the wife's name. Married people carefully enter their details in block capitals and post the forms off to depressed paper-pushers who then type that information into software front-ends whose forms are laid out and named in precisely the same fashion. And then they hit "submit" and the information is filed away electronically in databases which simply keel over or belch integrity errors when presented with something so profound as a man and another man who love each other enough to want to file joint tax returns.
[...] Believe it or not, this is actually a fractionally less stupid database schema.
- males
- id
- forename
- surname
- birthdate
- wife_id (unique foreign key references column females.id, may be NULL if male is unmarried)
- females
- id
- forename
- surname
- birthdate
This reduces the scope for ambiguity but it has suddenly become eye-poppingly sexist. Plus, what if you want to store information pertaining to the marriage itself? Like, the date it began?
Keep reading as he explains why you can't marry yourself, expands his database schema to cover polygamy, and eventually intransitive marriages:
The legal ramifications of what I'm about to describe are unguessable. I have no idea what rights a civil union like the ones which would be possible below would have, nor do I have any idea what kind of transhuman universe would require so complex a system. This is the marriage database schema to take us up to the thirty-first century, people.
"The real crime is that I'm not allowed to marry my database."
Truer words never spoken.
Not sure how seriously we should take this when unix still has the year 2038 rollover problem...
What?
You mean the Y292,277,026,596 problem?
Actually, according to my quick testing on this Linux box, there's a problem somewhere between Y1,141,709,097 and Y2,283,418,194. I'm guessing it's a Y2,147,483,648 problem due to years handled as signed 32-bit ints.
$ for i in {0..63}; do echo -n "$i: " ; date --date="@$((2**$i))"; done
[...]
31: Mon Jan 18 19:14:08 PST 2038
[...]
54: Fri Sep 22 07:13:04 PST 570855533
55: Sat Jun 12 22:26:08 PST 1141709097
56: date: time 72057594037927936 is out of range
[...]
63: date: time -9223372036854775808 is out of range
So, I guess we need to update the tm data structure sometime in the next couple billion years...
As with Y2038, this is fixed by installing a 64-bit CPU.
Testing disagrees with your comment:
$ for i in {0..63}; do echo -n "$i: " ; date --date="@$((2**$i))"; done
[snip]
55: Sat Jun 12 22:26:08 PST 1141709097
56: date: time 72057594037927936 is out of range
[snip]
$ uname -m
x86_64
That was on a 64-bit CPU. The sample output even includes dates past when the Y2038 bug hits. Installing a 64-bit CPU does not fix this.
time_t is a 64-bit int, but the "tm" struct holds 32-bit ints. That's when the year problem hits.
But, really, it's a couple billion years out. Hopefully, by the time we're on 2048-bit CPUs, we'll have increased the size of the ints in "tm" ... and given up on the Gregorian Calendar entirely, so that this isn't a problem for our robotic and/or insectoid successors.
You're right, ints are still 32 bits. I think I had blocked that out.
I'm in the middle of a discussion elsewhere advocating that Unix time_t seconds-since-epoch is a lost cause and we should change OSs to use 128-bit NTP time as their primary clock, converting to Unix time as necessary via a leap second table.
Do you have any idea what the NTP error bars will look like from one side of the Matrioshka Sphere to the other? Wake up sheeple.
Yeah but at least we won't be dicking with the timebase to keep pace with the rotational slowing of a planet we have long since disassembled.
Agree: what?
First computer job I did was setting up a membership DB for a Unitarian Universalist congregation. Off-the-shelf churchware existed, but everything we looked at assumed that families consisted of a "Mr." and "Mrs." and children sharing a single surname living at one address.
See also: questions like Do you have a Y chromosome? where you used to have a Sex:M/F option on forms...