Skip

Falsehoods Programmers Believe
June 18, 2012 4:23 PM   Subscribe

Falsehoods programmers believe about names and time shows how difficult it can be to represent basic concepts in code.
posted by Foci for Analysis (165 comments total) 49 users marked this as a favorite

 
Time is a basic concept?
posted by TheCavorter at 4:35 PM on June 18, 2012 [3 favorites]


I just want to be the first to say fuck you daylight savings time.

Fuck you daylight savings time.
posted by aspo at 4:36 PM on June 18, 2012 [51 favorites]


tldr:
Dear database programmer: have a look at Godel's incompleteness theorums. Program accordingly.
posted by Twang at 4:39 PM on June 18, 2012 [4 favorites]


If you write code that deals with time, you really need to read this book.
posted by jeffamaphone at 4:40 PM on June 18, 2012 [3 favorites]


I have been bitten by many many of those time issues. Having windows servers, none of which are on a domain, with wildly different times breaking all web service calls cuz we want to stop replay attacks. Having users in India timed out as soon as they logged in because the system thought they had been idle for many hours, oh yeah a "senior architect" implemented that one. I've gotten things like negative durations because a user's local clock was in a different timezone, they went past midnight and the server didn't. Never ever ever use local time for anything ever.
posted by Ad hominem at 4:40 PM on June 18, 2012 [5 favorites]


Time is a basic concept in that you have to get it (roughly) right before you can even begin to reason about your program's correctness in your problem domain. Time and names and unicode string handling and deployment are all table stakes.

I think these two lists could be turned around and used as ammunition when dealing with unrealistically short development-time estimates. The answer to "what do you mean it's going to take 2 weeks?!?" is usually something like "do you want it to work on Feb 29?"
posted by Fraxas at 4:40 PM on June 18, 2012 [22 favorites]


The interesting thing about these lists is that some of those things become truthier when you add the caveat "...I can effectively monetize" after "People."
posted by jeffamaphone at 4:43 PM on June 18, 2012 [2 favorites]


I think these two lists could be turned around and used as ammunition when dealing with unrealistically short development-time estimates.

Amen to that.
posted by jeffamaphone at 4:43 PM on June 18, 2012 [1 favorite]


Oh god I am flashing back to an epic fight I went through with some idiot in QA who simply refused to understand that EDT and EST were valid time zones, not typos. And that they were different times. On purpose.
posted by ook at 4:44 PM on June 18, 2012 [1 favorite]


Did they miss the cool fact that some minutes have 61 seconds?

Or, to quote from the applicable .h header file

The type tm
or struct tm in C.
include: <time.h>
Is used to represent a time in a structured form, with different components
for second, minute, hour, day, month, year, and day-of-week. Its definition
is as follows:
struct tm
{ int tm_sec; // 0 to 59 (or 60 for occasional rare leap-seconds)
int tm_min; // 0 to 59
int tm_hour; // 0 to 23
int tm_mday; // 1 to 31
int tm_mon; // 0 to 11, stupidly 0=January, 11=December
int tm_year; // year-1900, so 79 means 1979, 103 means 2003
int tm_wday; // 0 to 6, 0=Sunday, 1=Monday, ..., 6=Saturday
int tm_yday; // 0 to 365, 0=1st January
int tm_isdst; // 0 to 1, 1=DST is in effect, 0=it isn't
char *tm_zone; // time zone, e.g. "PDT", "EST".
int tm_gmtoff; } // time zone in seconds from GMT; EST=-18000, WET=3600
tm structures are produced from by localtime and gmtime.
tm structures are converted to strings by asctime.
tm structures are converted to seconds by mktime and .

posted by benito.strauss at 4:45 PM on June 18, 2012


It's more accurate to say that I don't CARE if you write your name using more than one character set. I won't accommodate you, because it's not worth it.
posted by thelonius at 4:47 PM on June 18, 2012 [16 favorites]


He forgot: "Time always moves forward."
posted by jeffamaphone at 4:47 PM on June 18, 2012 [3 favorites]


I'm reminded of the story of the developer who posited that their time zone implementation would be written to only handle integer-hour GMT offsets, because there can't possibly be enough people in non-integer offset time zones to care about. You can imagine their surprise when they found out what time it was in India.
posted by 0xFCAF at 4:47 PM on June 18, 2012 [12 favorites]


7. A week (or a month) always begins and ends in the same year.

The week thing I get, but a month that doesn't begin and end in the same year? Do they mean a month-long time span, but not a month?
posted by Pruitt-Igoe at 4:48 PM on June 18, 2012 [1 favorite]


Even Canada has a non-integer-hour time zone.
posted by Pruitt-Igoe at 4:49 PM on June 18, 2012


er, non-integer-hour-offset time zone
posted by Pruitt-Igoe at 4:50 PM on June 18, 2012


Yes, I suspect he means a month-long time span, but that may be only true in our (Gregorian) calendar.
posted by jeffamaphone at 4:51 PM on June 18, 2012



Relevant XKCD.

And yes, DST can die in a fucking fire of fiery fucking fire.
posted by Pogo_Fuzzybutt at 4:51 PM on June 18, 2012 [7 favorites]


35. September 2 is always followed by September 3.
posted by grouse at 4:52 PM on June 18, 2012 [3 favorites]


We created the naming mess ourselves. Calendars are all about cycles within cycles and choosing various values for when a cycle restarts. We try to line those things up with the movement of our planet and the sun (and/or the moon) but the damn things just refuse to move in a way that comes out even. Or even remains constant. And thus all sorts of crazy schemes have been devised to deal with it. But even without that issue getting modulus arithmetic correct for the purposes of calculating things like, "what day of the week is it 4 months from now correct is hard." When you have irregular length months and leap years and potentially resetting a larger cycle (e.g. rolling over the year), it's easy to mess these things up. And when you consider all the messing with things emperors and popes and such have done over the years, trying to write a program to calculate when easter was in any given year becomes fraught with peril. There is a reason you cannot set a Windows clock to before the year the Gregorian calendar was adopted, because, fuck that.
posted by jeffamaphone at 4:59 PM on June 18, 2012 [1 favorite]


36. Everybody uses the same calendar.
37. Years have 365 or 366 days.
38. Each calendar date is followed by the next in sequence, without skipping.
39. Calendar adjustments take place simultaneously.
40. Calendar adjustments take place mostly simultaneously.
41. A given date and/or time unambiguously identifies a unique moment.
posted by Joe in Australia at 5:00 PM on June 18, 2012


As recently as not that long ago, I've had problems with my hyphen generating boarding pass / frequent flyer membership / photo id mismatches. Yes it's true. Major airlines in the United States don't know how to program for the common hyphen. I can't imagine what people with actually unusual names go through.
posted by yeolcoatl at 5:02 PM on June 18, 2012 [1 favorite]


For the time one they missed: Knowing the hour offset from GMT is the same as knowing the local time.
posted by odinsdream at 5:13 PM on June 18, 2012 [1 favorite]


...or, rather, time zone.
posted by odinsdream at 5:14 PM on June 18, 2012


It would be great if all these hints came with examples. For example, if a year is not 365 or 366 days, how long could it be? 365.something days because of a leap second? And what is #38 about?
posted by Pruitt-Igoe at 5:15 PM on June 18, 2012 [1 favorite]


42. No one wants you to reprogram their system clock so that it always reads PARTY TIME
posted by Uppity Pigeon #2 at 5:17 PM on June 18, 2012 [10 favorites]


On December 31, 2008, all Google computers slowed their clocks slightly to accommodate the leap second. Google chose to slow their clocks rather than explicitly add the leap second because they were not convinced their systems would behave correctly when confronted with 23:59:60.
posted by ryanrs at 5:17 PM on June 18, 2012 [11 favorites]


For the time one they missed: Knowing the hour offset from GMT is the same as knowing the local time.

I have to wonder how many non-geeks (you know...The other 99.5% of the world) simply leave their time settings on forums, social sites, etc. set to default GMT because of this? Hell, how many regular users even know what GMT means?
posted by Thorzdad at 5:23 PM on June 18, 2012


Even Canada has a non-integer-hour-offset time zone

Someone I knew once spent a few weeks implementing and testing software for a satellite so that it could figure out what the local time was directly underneath it on the surface. Nine dimensional orbital mechanics, time and date rules, time zones, the whole works. This was used to tag the data the satellite was observing directly below. When the sat was eventually launched, he was disappointed because they put it into a sun-synchronous orbit. Every time it entered a new time zone, it was always noon. "Except for 12:30 in Newfoundland!" He had to console himself that if the satellite ever drifted off course at least it's clock would still be correct.


Here's one that I've seen in several financial systems:
43. A week is longer than a day.
The overnight loan rate is for one day, right? No, it's from one business day to the next business day. Okay, accounting for weekends means it's three days at the most, right? No, because you have to include business holidays. Did you know that several of the world's markets have week long holidays? Therefore we have that one day per year when the overnight settlement date matches the one week settlement date and all of the rate conversion routines in production start dividing by zero and crashing.
posted by ceribus peribus at 5:25 PM on June 18, 2012 [10 favorites]


Something that irks me about these articles (I read the 'names' ones when it was first published) was that the writers do not provide any solutions to the problems that they poses. To me, it seems to amount to saying (especially in the 'names' case), "There's no possible way of being able to represent names correctly."

Let's look through some of them:

People’s names fit within a certain defined amount of space.

So, in order to be 'correct' names must be allowed to be completely unbounded?

People have, at this point in time, one full name which they go by.
People have names.

Okay, smarty-pants. How would you account for this?

People’s names are all mapped in Unicode code points.

So, step 1 to creating a "correct" system that handles names: Be able to represent any possible writing system.

There exists an algorithm which transforms names and can be reversed losslessly. (Yes, yes, you can do it if your algorithm returns the input. You get a gold star.)

Wut??

Maybe what it is that's irking me about these articles is that they're a mixture of extremely useful and completely useless knowledge. If they separated out the practical information from the utterly esoteric, I would find these articles much more valuable.
posted by WaylandSmith at 5:27 PM on June 18, 2012 [12 favorites]


Calenderica. From the jeffamaphone link above ... this is pretty cool, actually.
posted by ZenMasterThis at 5:29 PM on June 18, 2012 [1 favorite]


Pruitt-Igoe: Lots of cultures use different calendars based on, e.g., lunar rather than solar cycles, or some combination of lunar and solar. But even if you restrict yourself to the solar calendar in common use today, you have things like the calendar adjustments when days were simply deleted from the calendar in order to fix up accumulated errors. These adjustments took place at different dates in different countries, and consequently a particular date (say: 1st of July, 1850) does not necessarily mean the same day in two different countries. Russia, in particular, adjusted very late - in the 1900s I think.
posted by Joe in Australia at 5:30 PM on June 18, 2012


40. People have names.

Name one person who does not have a name!

Just kidding. I think #40 is truthy and not a falsehood at all.
posted by bukvich at 5:37 PM on June 18, 2012


The day before Saturday is always Friday. (hint: False)

The takeaway here for programmers at all levels is if you find yourself importing modules having to do with time or calendrical calculations, ask another programmer to help you find a way to avoid it. The drastic case is that the use of such code requires director level approval with solid justification. The clock and the calendar are the source of a significant number of software failures. Both because they are inconsistent, and because management has a propensity for taking developer estimates and communicating them upward as deadlines.

We take time for granted, and often use it as a crutch. It can, and should be avoided when possible.
posted by jimfl at 5:39 PM on June 18, 2012 [3 favorites]


What I like about these two pieces is that they remind you there is no way to be right, just different ways of being less wrong.
posted by deo rei at 5:40 PM on June 18, 2012 [3 favorites]


Undecimber.
posted by combinatorial explosion at 5:41 PM on June 18, 2012


I frequently get error messages like, "Please do not include the number 1 before the area code," or, "If you typed in your social security number with dashes, please type it again without the dashes."

The code for checking and fixing that is shorter than the error message itself. WTF?
posted by StickyCarpet at 5:43 PM on June 18, 2012 [24 favorites]


We created the naming mess ourselves. Calendars are all about cycles within cycles and choosing various values for when a cycle restarts. We try to line those things up with the movement of our planet and the sun (and/or the moon) but the damn things just refuse to move in a way that comes out even. Or even remains constant. And thus all sorts of crazy schemes have been devised to deal with it.

What's worse is that all of these time conventions are maintained by stolid international committees that look backward to the 19th century and earlier (Roman times!) rather than the future. Time is ripe for some creative disruption. Since everyone looks up the time on their cellphone anyway, telecoms could pivot into "timecoms:" with your whole company on VerizonTM time all of these timezone/leap-second problems will just be cruft keeping your competitors from getting to market.
posted by ennui.bz at 5:44 PM on June 18, 2012 [1 favorite]


Google chose to slow their clocks rather than explicitly add the leap second because they were not convinced their systems would behave correctly when confronted with 23:59:60.

I'm under the impression NTP does this automatically. It uses adjtime to "slew" the time so as not to have jumps.
posted by Ad hominem at 5:47 PM on June 18, 2012


Left off the list:

A stopped clock is right twice a day.
posted by uosuaq at 5:48 PM on June 18, 2012 [1 favorite]


I want to throttle the people who decided Unix time needed to recognize leap seconds. And fuck everybody who decides to have a different DST than the rest of their time zone.
posted by 0xdeadc0de at 5:50 PM on June 18, 2012


Anyone else notice that metafilter's tags are written only in ascii?
posted by jeffburdges at 5:51 PM on June 18, 2012


Now I want to read a list about falsehoods programmers believe about space!
posted by TwelveTwo at 5:52 PM on June 18, 2012 [3 favorites]


What WaylandSmith said times, like, a meelyon. I work with a legacy database system with no validation at all. At all. I cannot stress enough: that way lies madness.

Here is some actual useful and entirely practical information about improving international support in your code: the Turkey Test.
posted by trunk muffins at 5:54 PM on June 18, 2012 [3 favorites]


Some notable quirks:

Wednesday 2 September 1752 was followed by Thursday 14 September 1752. (grouse?)

29 February, 1900 is valid date in Excel, so if you need that date, simply use Excel services.

I would love to switch to metric and GMT/UTC and, yeah, fuck DST.
posted by Monkey0nCrack at 5:54 PM on June 18, 2012 [1 favorite]


If it is this difficult to program properly for names and times in human software, think of how complicated Time Lord software must be! Is it "The Doctor," or "Doctor," or "Doctor, The" or "The Doctor, alias Theta Sigma," or "John Doe Time Lord, alias The Doctor"? And I don't even want to know what "wibbley wobbley, timey wimey" looks like in C++.
posted by Saxon Kane at 5:55 PM on June 18, 2012 [2 favorites]


telecoms could pivot into "timecoms:"

As a developer who has to deal with the concept that a user in TZ [A] needs to view real-time activity in TZ [B] through a host in TZ [C], [D], [E], etc... I will shoot myself if the telecoms start creating new times to deal with. God help me, but the potential for proprietary time zones? *BAM*
posted by timfinnie at 5:58 PM on June 18, 2012


Name one person who does not have a name!

The artist formerly known as the artist formerly known as Prince?

More realistically, there are situations (in police databases for example) where the name of an individual is unknown, redacted, hypothetical, or yet to be decided. One of the comments on the kalzumeus site mentions more cases: someone born into slavery, a feral child, an amnesiac, etc.

Of course, the problem isn't that names, times, or any other data can't be represented, it's that all of these edge cases and special scenarios also have to be accounted for if you want your system to be able to handle all situations. Just like how two digits isn't enough to represent a year, a sequence of ASCII characters isn't sufficient for name fields anymore if you want to handle all possibilities.
posted by ceribus peribus at 6:00 PM on June 18, 2012 [1 favorite]


Name one person who does not have a name!

"That guy". Y'know... "The Artist" hmmmm, currently known as "Prince" - but for awhile he had no "name" you could pronounce.
posted by jkaczor at 6:00 PM on June 18, 2012


Agh... ceribus...
posted by jkaczor at 6:01 PM on June 18, 2012


Any 24-hour period will always begin and end in the same day (or week, or month).

That's a damn stupid programmer.

I notice that leap seconds aren't even mentioned.
posted by DU at 6:02 PM on June 18, 2012


This is why you leave things like time up to a library, where a room of very smart programmers have already thought this stuff through.
posted by schmod at 6:04 PM on June 18, 2012 [3 favorites]


Name one person who does not have a name!

We call them "AUGMENTED".

I sort of slept through the meeting where they explained why.
posted by pompomtom at 6:04 PM on June 18, 2012


People have, at this point in time, one full name which they go by.
People have names

Okay, smarty-pants. How would you account for this?


Don't build a system to rely on a piece of information that may or may not exist.
posted by bleep at 6:07 PM on June 18, 2012 [4 favorites]


This is why you leave things like time up to a library, where a room of very smart programmers have already thought this stuff through.

See next week's article on Falsehoods Programmers Believe About Libraries.
posted by DU at 6:07 PM on June 18, 2012 [33 favorites]


"There's no possible way of being able to represent names correctly."

Well, yeah. That is probably quite true. But that doesn't mean that it's possible for some implementations to suck more than others. And the software engineer's dilemma is to try to aim for the least-sucky implementation given a fixed amount of time and resources.

Having a UTF-aware freeform text field (of type TEXT or VARCHAR(1024) or something on the backend) isn't perfect, but it's miles better than a typical Title-FirstName-MiddleInitial-LastName-Suffix combination that so much software uses.

The most important bit though isn't how you structure the columns though, it's in how you use the data and in particular what assumptions you make about it. E.g., it's crucial not to assume that names are static and unchanging, or that they're unique, or that there's a 1:1 mapping between names and people, etc. If you need something with any of those characteristics -- invariance, uniqueness, etc. -- then you need something else besides a person's name.
posted by Kadin2048 at 6:12 PM on June 18, 2012 [5 favorites]


room of very smart programmers

The number of rooms devoted to smart programmers is, even today, insufficient to deal with the problem...

The problem being that any number of rooms may be allocated to people who are empowered to just change the rules of time as they see fit.

We don't do DST. We do DST on a city border. We have a fractional DST in our area, which doesn't abide by State lines, County lines, or reason itself. We need to host our application inside of one of several DST/non-DST zones but want to run batch processes at a standard time regardless of locale. Arg.
posted by timfinnie at 6:19 PM on June 18, 2012


Hey, this could be a series! Next up: Falsehoods Programmers Believe About Mailing Addresses.
posted by Numenius at 6:23 PM on June 18, 2012 [2 favorites]


Some of these are real "falsehoods programmers believe", but others seem more like "edge cases that programmers don't care enough about to take the time to handle them properly". But then there's this:
"Months have either 30 or 31 days."
Huh? Who believes this?
posted by Flunkie at 6:24 PM on June 18, 2012 [1 favorite]


As a business analyst who spends most of his worktime capturing, writing, and reviewing requirements, I feel I should bookmark this in my "reasons I have a job" folder.
posted by MCMikeNamara at 6:25 PM on June 18, 2012


Saxon Kane: You think concurrent multithreaded programming is a pain, try multithreadded programming on a processor that is capable of independently clocking each thread forwards, backwards, sideways, or out of order.

You don't validate your message passing properly and you can potentially create a paradox that wipes out reality. Visual Studio Aleph-Null for TARDIS has an option to enforce paradox checking before compile, but everyone just turns it off.
posted by Grimgrin at 6:27 PM on June 18, 2012 [3 favorites]


These lists are full of assertions of problems without either an analysis of whether it's worth fixing them, or what potential solutions would be. From a programming perspective that makes them irrelevant. Should you program international systems to accept non-ASCII characters? If there's reason to, sure. Other than that, I don't see why any of this is even relevant to 99% of programming tasks.
posted by graymouser at 6:28 PM on June 18, 2012 [2 favorites]


Ah yes.
Much amusement was had on 29 February 2012 here in Australia when HiCaps, a service that processes private health insurance claims (run by the National Australia Bank) insisted that 29/02 was an invalid date.
posted by goshling at 6:29 PM on June 18, 2012


Also, don't assume that numeric digits in dates or timestamps always represent values in base-10. Timestamps in tar archives, for example, are in octal.
posted by TwoToneRow at 6:36 PM on June 18, 2012


I used to work on BD+, the DRM system that Fox uses on all its Blu-Ray discs. The DRM code does a lot of sanity checking to make sure it's running in a real Blu-Ray player, as opposed to running inside some pirate hacker's emulator.

We got a bug report that none of our discs would play in New Zealand--in the summer. Any other place and time was fine.

It turned out that New Zealand observes daylight savings time in the summer, during which they are 13 hours ahead of UTC. This freaked out the DRM system and in its paranoia, it refused to play discs!
posted by jjwiseman at 6:39 PM on June 18, 2012 [6 favorites]


Ad hominem: I'm under the impression NTP does this automatically. It uses adjtime to "slew" the time so as not to have jumps.

Not so much:
http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
posted by zeypher at 6:42 PM on June 18, 2012


Even Canada has a non-integer-hour time zone.

Which brings up another false assumption: every time zone in a given country starts and ends DST at the same time of day.
posted by one more dead town's last parade at 6:50 PM on June 18, 2012


In the system I was working on during the leadup to Y2K, we discovered several instances of incorrect leap year handling. Most of them were fine in practice*, because the problem was that the programmer just did "year divisible by four", which would work fine in 2000. But there were two or three in which they did "year divisible by four but not by 100", leaving off the "unless by 400", which would cause it to break in 2000. This always seemed odd to me - they knew about the 100 part, but not the 400 part?

*: Fine in practice until 2100, at least, but screw programmers from 2100, always lording it up over the rest of us with their fancy-schmancy yottabit processors
posted by Flunkie at 6:51 PM on June 18, 2012 [1 favorite]


Re names: this is why programmers insist on assigning everyone an ID in the database. Of course, if you do that, people cry foul on Privacy Violations, but it's that or not be able to do anything.
posted by Xany at 6:53 PM on June 18, 2012


The code for checking and fixing that is shorter than the error message itself. WTF?

See also:

Python 3.2.3 (default, Apr 23 2012, 23:14:44)
[GCC 4.7.0 20120414 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> quit
Use quit() or Ctrl-D (i.e. EOF) to exit
>>>

IF YOU'RE GOING TO PUT THE SPECIAL CASE IN ANYWAY YOU SMUG FUCKS
posted by enn at 6:57 PM on June 18, 2012 [19 favorites]


A lot of people learned leap years were every 4 years when they were kids, and stayed with that. I didn't know about the divisible by 100 and 400 exceptions until I became a programmer and started learning.....stuff like that. I guess an extra day every 4 years is a LITTLE too much? So they start tinkering with the formula.
posted by thelonius at 7:00 PM on June 18, 2012


God help you if you have to deal with time/dates in JavaScript.
posted by deathpanels at 7:10 PM on June 18, 2012


This is not what programmers don't understand about time. That is what some shitty code he looked at and had to refactor didn't understand about time. There are lot of programmers in the world, and he has not met most of them.
posted by braksandwich at 7:11 PM on June 18, 2012


Kadin2048 : Having a UTF-aware freeform text field (of type TEXT or VARCHAR(1024) or something on the backend) isn't perfect, but it's miles better than a typical Title-FirstName-MiddleInitial-LastName-Suffix combination that so much software uses.

From now on I am going to insist that my name is 𝔄𝔫𝔡𝔯𝔢𝔴𝔖𝔱𝔢𝔭𝔥𝔢𝔫𝔰 on all official correspondence. We'll see how well my bank handles it.

More seriously, computers will handle random UTF-8 characters just fine, the problem is the humans in the chain. Nothing (technical) is stopping a bank account from having an account name with Chinese characters, but in an English-speaking country the guy on the end of the phone is going to have trouble accessing your information when you ring up with a query. "Excuse me sir, how do you spell 楊?"
posted by AndrewStephens at 7:17 PM on June 18, 2012 [6 favorites]


Also, Chrome on Windows sucks at displaying unusual characters. It gets most of Unicode right but I want my blackletter, dammit.
posted by AndrewStephens at 7:20 PM on June 18, 2012


Thank you, AndrewStephens. You, plus this, have made my day that much more interesting.
posted by 23 at 7:26 PM on June 18, 2012 [3 favorites]


This list is excellent, and it was written by a smart, careful, thoughtful programmer. I know, because I just got done working with Noah, where he was our head of QA. It's reasonable that he moved on. He kicked ass, he took names, now he's doing something else.

I also want to comment on ryanrs assertion that Google slowed the clocks down on their servers rather than deal with 23:59:60. I don't work for google, so I wouldn't know. But I DID work for Yahoo early in the 2000's. I remember coming back from New Year's break, and someone mentioned that there was, in fact, exactly thisproblem. All the machines that served search requests were running red hat, and we got a kernel panic on every single machine at the stroke of midnight-leap-second. Woops. Needless to say, the on call staff were slow to realize, although they noticed before any reasonable time the next day.
posted by Phredward at 7:38 PM on June 18, 2012 [2 favorites]


No love for February 30th?
posted by Chrysostom at 7:53 PM on June 18, 2012 [1 favorite]


pshaw. time doesn't even exi
posted by not_on_display at 8:04 PM on June 18, 2012


I have a last name that's actually comprised of two "words" separated by a space. It's amazing the number of systems that can't handle this. It's gotten better in recent years, but I often get the two scrunched together without the space or get an error when I try to enter the space. This is kind of frustrating especially in systems which tell you to enter the name exactly as you have it on your form of ID -- for example, ETS's system for registering for the GRE. My passport has my last name with the space but the system refused to accept it.
posted by peacheater at 8:04 PM on June 18, 2012 [1 favorite]


When I was an architect for a major relational database system, one of the things I had to specify was the rules of date arithmetic. The programmers were appalled that century years not divisible by 400 were not leap years.

"You made that up!"
"No, really."
"So 2000 isn't going to be a leap year?"
"It will be, because 2000 divides evenly by 400."
"Don't they all?"
"No, 1900 and 1800 weren't."
"But there were presidential elections in those years!"
"That's a different rule set."
"I still think you're messing with me."
"No, really."
  ...
"Well even if you're right, most people don't know that rule. Shouldn't we use the rule everyone knows?"
posted by ubiquity at 8:05 PM on June 18, 2012 [5 favorites]


I don't work for google, so I wouldn't know.

Google Leap Smear
posted by odinsdream at 8:09 PM on June 18, 2012


According to Joel Splotsky, Excel thinks that 1900 was a leap year. This is because Lotus 1-2-3 had made this error, and they wanted to make sure that Excel would work for Lotus users' converted data.
posted by thelonius at 8:20 PM on June 18, 2012 [4 favorites]


All countries make the switch to daylight savings on the same day.
posted by rjnerd at 8:39 PM on June 18, 2012


Use quit() or Ctrl-D (i.e. EOF) to exit
IF YOU'RE GOING TO PUT THE SPECIAL CASE IN ANYWAY YOU SMUG FUCKS


There's no special case, just an object in the __builtins__ namespace, called "quit", with __call__ and __repr__ methods. If you call it, it quits the interpreter. If you ask for its repr, it returns the above string. Should they have made the repr quit the interpreter? That'd be a huge violation of the interface and norms — I mean, you'd have an object which kills the interpreter when you try to inspect it! "You'll never take me alive, debugger!" Is that what you want?
posted by stebulus at 8:40 PM on June 18, 2012 [25 favorites]


Falsehoods Programmers Believe About Mailing Addresses.

I was looking into an issue with a letter printing service once for an Irish company. Somebody wasn't getting their confirmation letter in the post. First thing I do is check their address, and it was 'The red cottage at the top of Kearney, Cork County.' (Not that exactly, but you get the idea..) Obviously I had found the problem, we just needed their real address. Turns out that in Ireland, that was a perfectly valid mailing address.

In the end the issue was some malformed XML or something mundane like that.

So I guess my lesson was, 1) address can be surprising and 2) don't build XML by string concatenation.
posted by papercrane at 8:42 PM on June 18, 2012 [3 favorites]


Falsehoods Programmers Believe About Mailing Addresses.

*sobs as he thinks about the insurance database he deals with*
posted by kmz at 8:51 PM on June 18, 2012


The general problem I have with articles like that is that it often seems the author are tooting their own horns about how smart they are to notice and catalog such things. In my mind, at least, the smart ones don't just list the problems but also offer potential solutions, or, in this case, suggested code to avert such issues.
posted by Samizdata at 9:02 PM on June 18, 2012 [2 favorites]


I could write one called "Things programmers believe about URLs."
posted by jeffamaphone at 9:11 PM on June 18, 2012 [2 favorites]


> There's no special case, just an object in the __builtins__ namespace, called "quit", with __call__ and __repr__ methods. If you call it, it quits the interpreter. If you ask for its repr, it returns the above string. Should they have made the repr quit the interpreter? That'd be a huge violation of the interface and norms — I mean, you'd have an object which kills the interpreter when you try to inspect it! "You'll never take me alive, debugger!" Is that what you want?

No, what I want for 'quit' to be syntax in the REPL loop. Yes, this would mean adding a keyword. Yes, it wouldn't be as 'clean'. USABILITY MOTHERFUCKER, DO YOU SPEAK IT. oh no wait you don't that would be unpythonic
posted by Fraxas at 9:12 PM on June 18, 2012 [2 favorites]


Falsehoods Programmers Believe About Mailing Addresses.

I once had a temp job taking sales calls for a specialty mail-order company. They used UPS for delivery, so PO box numbers weren't allowed; every order had to go to an actual street address. The ordering system required a ZIP+4 code to be entered. If the customer didn't know theirs, we were to go to the USPS website and look it up there.

At the time, I lived on a short street that was so close to the post office, they decided to give everyone on that street a complimentary PO box rather than send a truck. As a result, that street isn't in the USPS database, and has no ZIP+4 code assigned to it.

I asked the instructor what I should do if that comes up on an order I take. He seemed surprised that that could happen, and said he'd look into it. He never got back to me, and it never came up on any of the calls I took. This was nearly ten years ago, and I have no idea if they're still using the same system.
posted by reprise the theme song and roll the credits at 9:28 PM on June 18, 2012


this would mean adding a keyword.

Yeah, I'm down with that.
posted by stebulus at 9:31 PM on June 18, 2012


Hi, Pope Gregory XIII here. No, You are not getting those 11 days back. Oh, and you are now all called Jams O'Donnell
posted by fallingbadgers at 9:45 PM on June 18, 2012 [3 favorites]


Here is some actual useful and entirely practical information about improving international support in your code: the Turkey Test.

Mr. Moser is making another really common incorrect assumption: "zip codes can be safely parsed as integers." It'll work in most of the US, but in some parts of New England it'll drop the leading 0 (or worse, try to parse it as octal). And if he needs to deal with codes from exotic locales like Canada, he's in real trouble, since their postal codes are alphanumeric.

I learned this the hard way
posted by I've a Horse Outside at 9:52 PM on June 18, 2012


Re names: this is why programmers insist on assigning everyone an ID in the database. Of course, if you do that, people cry foul on Privacy Violations, but it's that or not be able to do anything.

um, that's really just how databases work - almost everything in a database gets an id.
posted by bitdamaged at 9:59 PM on June 18, 2012 [1 favorite]


Goddammit!

Look, it's the same time everywhere, all the time. Except if you are in a speeding vehicle, then it's a little slower.

It's never tomorrow in Japan or Australia until it's tomorrow here. Okay, maybe in Australia.

Never mind.

I hate DLST. Always.
posted by mule98J at 10:18 PM on June 18, 2012 [1 favorite]


um, that's really just how databases work - almost everything in a database gets an id.

That's true, but I think it misses the point. Yes, sticking a bigint sequence on your users table is probably an excellent practice. However, some developers seem to feel that a column that represents nothing about the record itself and is only there for bookkeeping is distasteful.* This can lead to such foolhardiness as, for example, using name as a primary key.

For a real-world example, my doctor's office has a "patient portal" where I can log in and view my test results, email my doctor, etc. The username scheme is firstnameLASTNAMEbirthyear. Some developer evidently thought this scheme was sufficient to produce a unique identifier. I have no doubt they were mostly right...but I also believe they've been proven wrong in at least one case, and either the system has been patched or its administrators have developed a workaround. Either way, the system now works as it should've in the first place: users have a login, which may or may not be their name and birth year; this login is associated with their full name as they want it displayed; it is also associated with some paperwork-friendly unique identifier (probably SSN).

*I've never interrogated anyone on this viewpoint and may accidentally be misrepresenting it
posted by I've a Horse Outside at 10:33 PM on June 18, 2012


...using name as a primary key...

Ugh. I thought I successfully suppressed all those memories.

When can we talk about the falsehoods programmers believe about money? Because I can name several US state budgeting systems that have no systematic way to deal with fractions of cents. The literal architectural argument I heard is that some code will round up, and some code will round down, so it should all just even out in the end, right?
posted by NoRelationToLea at 10:51 PM on June 18, 2012 [2 favorites]


Two things (already mentioned):

1) Fuck DST, hard, with a spiked steel pole.
2) These are (mostly) useless without examples.
posted by MikeKD at 11:15 PM on June 18, 2012 [1 favorite]


Addresses would definitely be an interesting one. For example:
  • There are ZIP codes everywhere. (Not in most of Ireland!)
  • Streets have names. (Not in most of Japan!)
  • Houses have numbers. (Yeah, right.)
  • Everyone specifies addresses in the same order. (Japan specifies largest-to-smallest, different countries put the ZIP code before or after the city name.)
  • Each line of the address is at most X characters long.
  • Each house has one unique address.
  • ...
posted by Zarkonnen at 11:18 PM on June 18, 2012 [3 favorites]


Identical triplet babies whose only relatives are missing may need probabilistic identifiers.
posted by StickyCarpet at 11:33 PM on June 18, 2012 [1 favorite]


Because I can name several US state budgeting systems that have no systematic way to deal with fractions of cents.

That's really odd, because I thought that there was a universal method of rounding numbers in bookkeeping (round half to even). It's even an IEEE standard (754).
posted by WaylandSmith at 11:38 PM on June 18, 2012


Addresses would definitely be an interesting one. For example:
  • Every country has something analogous to states or provinces
I can't even begin to guess how many times I've specified a state called "N/A" or "-" in a form just to satisfy a stupid validator. Fortunately mail comes in just fine with that printed on the label.
posted by jklaiho at 11:42 PM on June 18, 2012 [1 favorite]


11. People’s names are all mapped in Unicode code points.

This is damned scary. I'd like to know why this isn't true. Is it about some names not having written representations at all (in which case you're fucked no matter what), or Unicode not (yet) having all the necessary code points? If the latter, they need to get on this and not just concentrate on adding literal shit like this to the standard.
posted by jklaiho at 11:49 PM on June 18, 2012 [1 favorite]


I've always enjoyed showing non-programmers the Time Zone Database (also known as tz or zoneinfo). 200+ kb gzipped worth of rules just to tell the time.
posted by srboisvert at 1:10 AM on June 19, 2012


•Every country has something analogous to states or provinces

• Whenever a country has states or provinces, they are part of the address.

The Netherlands have provinces, but they're not relevant for sorting and delivering mail. That's what our (alphanumerical) zip-code is for. Adding the province would just confuse matters.
posted by Sourisnoire at 3:09 AM on June 19, 2012 [1 favorite]


The overnight loan rate is for one day, right? No, it's from one business day to the next business day. Okay, accounting for weekends means it's three days at the most, right? No, because you have to include business holidays.

Which reminds me. So you've programmed your system to take into account that you can only sent a specific type of payment on business days and you know that files can be sent, but won't be processed that day.

But do you know that this particular kind of payment is sent to a central processing point in another country, that may just have quite different holidays and business days, that said point might just automagically shift the execution date of your payment to the first available business day and that this does or does not take into account whether or not this business day in the original country could be a holiday?

Oh and worse, those payments you sent might include bookings for different countries from the two you've already taken into consideration and their business days might be different again, especially when some feckers decide to extend an existing bank holiday for another day for cheap political gain.

And remember, all of this takes place within the same bank and with the same currency, where at least you can have a pretence at joined up thinking.

Now you know why they pay me the big bucks to test all this.

Because programmers are lazy and prone to make the easiest assumptions.
posted by MartinWisse at 3:18 AM on June 19, 2012


Addresses would definitely be an interesting one.

Apartment/flat numbers and building numbers are abbreviated the opposite way in Australia and the UK (or my part of it, at least).

23/4 Example Street, Melbourne, is flat number 23 at 4 Example Street.

23/4 Example Street, Edinburgh, is flat number 4 at 23 Example Street.

Plenty of address forms don't like slashes, either.
posted by rory at 3:43 AM on June 19, 2012


Maybe what it is that's irking me about these articles is that they're a mixture of extremely useful and completely useless knowledge

That's how hacker humor works, get used to it.

11. People’s names are all mapped in Unicode code points.


This is damned scary. I'd like to know why this isn't true.
I believe there are Chinese cultures where it's traditional to write your name as a picture. It's not all that weird for them, because traditional Chinese hanzi require a measure of calligraphic ability to write. Sometimes the name is made of radicals from regular hanzi mashed together in a new way that Unicode doesn't know about.

I think this case could be handled adequately by having a name field in UTF-8 and a signature field in PNG.
posted by LogicalDash at 3:51 AM on June 19, 2012


Here is some actual useful and entirely practical information about improving international support in your code: the Turkey Test.

That's not the Turkey test, that's the old "who the fsck is so stupid as to use a date format in which you put the month first, followed by the day and year, when any sane person would do either year-month-day or day-month-year and why are they so provincial to think any country that does use a sane format is the exception" problem.

I know the US is not a very innovative, science minded country and proud to cling to its outmoded traditions and habits, but this is so inherently bad a convention it surprises me that even Americans still use it.

ObClarkson: on the other hand, every programmer who doesn't take this into account deserves to be shot in front of their families.
posted by MartinWisse at 3:51 AM on June 19, 2012 [4 favorites]


Having unique IDs in your database is not a privacy violation. The privacy violations happen when the designers notice that they already have a field for everyone's Social Security Number, which is already unique, and which everyone has to provide to get entered into that payroll or roster or whatever.
posted by LogicalDash at 3:53 AM on June 19, 2012


Addresses would definitely be an interesting one.

I assure you, whatever you can dream up the Google Maps people have already dealt with, FWIW.

I really like these articles, but really hate the titles. I am a programmer, but I don't believe all of these falsehoods and feel vaguely insulted that I get lumped in with people who made these coding assumptions.

It's hard to come up with a catchy title. I'd probably go with "Notes on the intricacies of date/time formats," for instance. But that would probably get me fewer readers.
posted by A dead Quaker at 3:56 AM on June 19, 2012


The title says "programmers," not "all programmers".

Things Programmers Believe About English Grammar.
posted by LogicalDash at 3:57 AM on June 19, 2012 [5 favorites]


Apartment/flat numbers and building numbers are abbreviated the opposite way in Australia and the UK

In the UK the utilities companies use some sort of master database for residences. My current flat is in it three times. Once as Flat 1, once as GFF (ground floor flat) and once as Flat A. Huge hassle! At one point we had 3 different companies claiming to be our electrical suppliers and 2 others as gas suppliers. I

This is why I am automatically sceptical of any database related government management efficiency claims. They can't even sort out the accuracy of a database of big huge physical stationary real world things. How will they manage with things like illnesses, employment or immigration?
posted by srboisvert at 4:00 AM on June 19, 2012


In the UAE, streets are numbered by the city planners, but no one knows the street numbers. Mail is always delivered to post office boxes, so forms that require street addresses become a nightmare.
posted by bardophile at 4:12 AM on June 19, 2012


I should say, no one *uses the street numbers, and most people have no clue that they even exist.
posted by bardophile at 4:13 AM on June 19, 2012


Most of the time, you really don't need to care about half these rules. Date stuff'll catch you out anyway, and even if you've a half decent Date/Time library your time is going to be better served fixing the shit that's likely to break.

Remember, "fast; good; cheap, pick two." You can get away with not programming to every exception if those exceptions are rare enough. Every solution is an approximation, and when you start forgetting this, you start creating unmaintainable & broken code.
posted by zoo at 4:50 AM on June 19, 2012 [1 favorite]


Spotify apparently hasn't learnt the rule that some bands have the same name as other bands. It's always pretty shocking when one album finishes and another one starts, and your favourite sludge-metal band suddenly start playing 70s-influenced female-fronted horn-rock.
posted by dudekiller at 5:37 AM on June 19, 2012


Programmers have enough trouble with variable scope and extant which are way easier than subtle social intricacies of human names and time spans. The list of true things about names and time as we use them is short, highly conditional and possibly could be combined. Here's a start.

1. Humans often use names to refer to one another.

2. Humans often also name time intervals when believed convenient.
posted by wobh at 5:41 AM on June 19, 2012


He forgot: "Time always moves forward."
posted by jeffamaphone at 4:47 PM on June 18


Time keeps on slippin' slippin' slippin'… into the future… tick tock tick… doot doot doo doo
posted by readyfreddy at 6:03 AM on June 19, 2012


I'm under the impression NTP does this automatically. It uses adjtime to "slew" the time so as not to have jumps.

I know very little about this, but my impression was that NTP slews to the correct time so that you don't have problems with missing or extra seconds popping up when time correction is occurring. It's bad to have the wrong time, but it is REALLY BAD to over-correct and end up with things happening in order, but when they pull timestamps from the overcorrecting clock, they are getting out-of-order timestamps. Every second that is supposed to happen happens, it just happens at a faster or slower rate so that the system clock can sync up with the external time source.

But with a leap second, you have an extra second that is supposed to happen. So it sounds like what they did was use NTPs slew mechanism to keep the computers ignorant and happy. Something like taking away one second from the time source so the computers will slow down, and then adding two seconds back in when they were halfway done.

(This is where the UNIX epoch system is kind of a brilliant idea. As far as the system is concerned, time is a march of seconds. What we name them is up to the user. And I think that's where people, and programmers, get screwed up in things like this. We get stuck in the "what's the name of the thing" versus the more important "what is actually happening" thing.)

This is also yet another thing that Novell Netware took seriously (and got mostly right) before anyone else cared about such things. Timesync is important, and it is build right in and a big part of the OS. If memory serves, it is implemented in Novell's typically mysterious way, but it works.
posted by gjc at 6:07 AM on June 19, 2012


I know the US is not a very innovative, science minded country and proud to cling to its outmoded traditions and habits, but this is so inherently bad a convention it surprises me that even Americans still use it. -MartinWisse

Poppycock! The US military uses DMY. And while we're on the topic of ludicrous numerical habits, what's with stones anyway? As in "the Queen has lost three stone". Oh right, it's that convenient divisor/multiplier of 14. Brilliant.
posted by readyfreddy at 6:11 AM on June 19, 2012


As someone who builds databases, I've discovered years ago that the real world and formalism hate each other with a passion.
Formalism: here's a neat little square box I just made for you, please step inside
Real world (sprouts a new tentacle): ha ha ha
posted by elgilito at 6:12 AM on June 19, 2012 [10 favorites]


Because I can name several US state budgeting systems that have no systematic way to deal with fractions of cents.

That's really odd, because I thought that there was a universal method of rounding numbers in bookkeeping (round half to even). It's even an IEEE standard (754).


I think the rounding is supposed to occur only on the input or output of the calculation (like when printing checks or bills) so that your total loss is limited to a fraction of a penny. If the rounding occurs inside the calculation, you can end up with losses of much higher magnitudes.

If I'm buying 1000 widgets and they cost $0.014 a piece, and someone rounds in the middle, someone is losing or gaining $4.
posted by gjc at 6:13 AM on June 19, 2012


I always wished that the standards people would rework the calendar and time units such that every month had 30 days (ie change the length of a second, etc, even including leap years into the equation). it'd fuck up a lot of people for a long time, but after the learning curve, it would be awesome.
posted by readyfreddy at 6:20 AM on June 19, 2012


I know the US is not a very innovative, science minded country and proud to cling to its outmoded traditions and habits, but this is so inherently bad a convention it surprises me that even Americans still use it. -MartinWisse

Poppycock! The US military uses DMY.


I'm sure every country has their share of programmers (and designers and architects and so on) who mistake the nominal notation from the actual calculations. It isn't that the US is stupid for liking 6/19/12, it is the idiot who tries to do math on the reverse American notation without sanitizing the input correctly.

(I would note that there is some symmetry in that notation- each successive spot can have higher numbers. [1-12] / [1-31] / [0-99] )
posted by gjc at 6:21 AM on June 19, 2012


MetaFilter: that would be unpythonic
posted by Foosnark at 6:40 AM on June 19, 2012


You can get away with not programming to every exception if those exceptions are rare enough. Every solution is an approximation, and when you start forgetting this, you start creating unmaintainable & broken code.

This is also very true. Sometimes, you are allowed to cheat. Just document your cheats please.

Please?
posted by MartinWisse at 6:44 AM on June 19, 2012 [1 favorite]


There's a beauty in how the clock widget of every user interface marks an intrusion into the digital symbolic order, how our business systems and high-tech electronics are still measuring in terms of Roman gods and emperors, agricultural and astronomical cycles. This clean and enlightened society is a big messy legacy.

If programmers had more power, refactoring code would ultimately mean refactoring the world, and probably devolve into a fascist struggle to keep everything clean and tidy and hierarchical. To me it seems like the political aspects of software are extremely important.

The digital realpolitik of database schemas and network architectures, etc. There's got to be a lot written about this. Any pointers?
posted by mbrock at 6:46 AM on June 19, 2012 [5 favorites]


tchrist's hints on reasonable assumptions for using UTF-8 in Perl is gleefully informative.
posted by scruss at 6:47 AM on June 19, 2012 [1 favorite]


This is not what programmers don't understand about time.

The opinions about names and time that are implied by the behaviour of this program are its own and may not reflect beliefs of its author.
posted by sfenders at 6:49 AM on June 19, 2012


As it happens, on Sunday I tried to calculate the distance in degrees that the sun moves (or the Earth rotates, if you want to be precise) in an hour.* It's really fucking complicated to do it with actual precision.

*I have an idea for a solar energy collector that turns to track the sun and I wanted to rough it out using lego.
posted by gauche at 6:56 AM on June 19, 2012


He forgot: "Time always moves forward."

Well, time travel is often a necessary but overlooked aspect of e.g. social security payments systems, where you have different implementations of different laws that are valid on different times.

E.g. a changeover in the length of your unemployement benefits that needs to award anybody before 01-01-2012 with ruleset foo and after 01-01-2012 with ruleset bar.
posted by MartinWisse at 7:03 AM on June 19, 2012


We all know the first job a new programmer should have is writing a custom time/date class (with pursuant converters)
posted by k5.user at 7:06 AM on June 19, 2012


bukvich: "40. People have names.

Name one person who does not have a name!

Just kidding. I think #40 is truthy and not a falsehood at all.
"

It's actually addressed in the comments: babies below a certain age in some countries (whose parents might see a need to register them in a website), and so on.
posted by IAmBroom at 7:17 AM on June 19, 2012


Several of the name problems are solved in New Zealand by law.

A list provided by the Internal Affairs Department shows 350 parents had the names they chose for their offspring rejected in the 10 years ending June 30, 2011.
...
Mafia No Fear, Anal, V8, single letters, the Roman numerals I, II, III, punctuation symbols * . and / and titles such as President, Emperor, Chief, Constable, Sargent and General were also rejected.

Names could not be more than 100 characters, use an unearned title, or be offensive to the general public, he said.

Names also had to be actual words, not numbers or symbols.

posted by WhackyparseThis at 7:20 AM on June 19, 2012


ceribus peribus: "The artist formerly known as the artist formerly known as Prince? "

jkaczor: ""That guy". Y'know... "The Artist" hmmmm, currently known as "Prince" - but for awhile he had no "name" you could pronounce."

Wrong. For purposes of entering his name into computer systems, the court allowed him to also register "The Artist Formerly Known As Prince"* as his name. He anticipated this problem.

*Not sure of the capitalization, but, really...
posted by IAmBroom at 7:23 AM on June 19, 2012


Clarifying my statement about time not always moving forward: Windows has a function called GetTickCount(). It returns the number of "ticks" since the system booted. Never mind the fact that ticks are very inaccurate; it's generally assumed by novice users this number only goes up. But it's a 32 bit number so it overflows back to zero every 29 days or so. Have a Windows machine that blue screens every 29 days reliably? Someone didn't do their math right in a driver. Debug versions of windows start with an uptime right before the overflow to try to catch these errors.

Also users can manually set their clocks backward at anytime. The IE history database (which i owned for awhile) did not like this and strange things would happen. I resolved the bugs as "don't do that."

Certain authentication schemes (like Kerberos) depend on clients and servers having approximately the same time. How far apart they can be is configurable but increases vulnerability. Try setting your clock back a year and then streaming a movie on Netflix: not allowed.
posted by jeffamaphone at 7:35 AM on June 19, 2012


I'm a programmer and I know enough to always use standard libraries for anything remotely non-trivial, definitely including time/date arithmetic.

Regarding names, everyone everywhere with a passport has an "official" "international" name in the ISO Latin character set. Generally as a systems developer you only need this to be able to put "Hello {name}" on generated communications anyway, and for call centre employees to be able to say the same. A chosen (unique) username or (unique) email address normal - only my bank and UK government agencies have diverged from this and each chosen to assign me a very long numeric ID which is required for login instead; sigh.
posted by dickasso at 7:45 AM on June 19, 2012


Pruitt-Igoe: For example, if a year is not 365 or 366 days, how long could it be?
alduin$ TZ=BST cal 09 1752
   September 1752     
Su Mo Tu We Th Fr Sa  
       1  2 14 15 16  
17 18 19 20 21 22 23  
24 25 26 27 28 29 30  
F'rinstance.

I think the majority of the later items in the list linked in the original post can be summarized as "Your project does not have anything close to the time or budget to handle names in a fully general way, so deal with the cases that actually matter to a significant fraction of your user base. Perfect is the enemy of finished."
posted by sourcequench at 7:59 AM on June 19, 2012 [1 favorite]


How often do programs written today need to deal with the changing of the calendar in 1752, though? (Sincerely curious here.)
posted by jeather at 8:10 AM on June 19, 2012 [1 favorite]


His list for time doesn't include most of the problems I ever see with time. I used to be on the team that did supervisory work for timezone package updates. One of the stranger things I learned is this:

Time zones change *constantly*. When somebody new comes to be in power in a nation, one of the first things they do is often to change the time. I don't know why; maybe they think they're optimizing something, maybe they think it's just cool to be able to do so. But you see this all the time. Countries (and states, counties, and cities) move between time zones, move the dates they observe DST on, and change the names of their time zone (without actually causing net change in the current time) on a constant basis.

As a result, if you've got software that does a good job of keeping track of what time zone is where, the data for that will be a staple of your software updates. That software will be, by far, the most frequent piece of software you release updates for.

Here's an example month. In March of this year, the following legal changes were made which will, somewhere, alter the answer to "what time is it?": (not sorted by time for obvious reasons)
  • On 09-Mar-2012, Morocco announced that they'd observe DST on 25-Mar-2012
  • On 09-Mar-2012, Morocco announced that they wouldn't observe DST during Ramadan, but didn't specify exactly what time (on 20-Jul-2012) they'd stop observing DST or what time (on 18-Aug-2012) they would resume DST.
  • On 15-Mar-2012, Morocco announced that they'd observe DST on 29-Apr-2012
  • Armenia announced that their previous announcement that they'd observe DST starting 24-Apr-2012 would not be honored
  • The Falkland Islands announced that they would remain on Falklands Summer Time throughout 2012 and will continue to remain on summer time until otherwise announced
  • Cuba moved the switch to DST from 11-Mar-2012 to 01-Apr-2012
  • On 10-Mar-2012, Haiti announced that as of 07-Mar-2012 they had plans to observe DST starting 11-Mar-2012. Thanks for the advanced notice.
  • On 26-Mar-2012, Syria announced that it would start observing DST on 30-Mar-2012
  • On 26-Mar-2012, Gaza and the West bank were announced to be switching to DST on 30-Mar-2012
The ones that give you 12-hours of notice are the fun ones.
posted by atbash at 8:24 AM on June 19, 2012 [6 favorites]


How often do programs written today need to deal with the changing of the calendar in 1752, though? (Sincerely curious here.)

Not often. It's unlikely you'll need to enter an appointment for 02-Sep-1752 into your calendar[1]. Most software just gets that one wrong.

One interesting note on this point is that such things do occasionally have grave consequences. One of the reasons Napoleon was defeated at Waterloo, rather than at the earlier Battle of Austerlitz, was that the Russians and the Austrians had agreed to combine their forces on a particular date. Unfortunately, the Russians didn't switch to the Gregorian calendar until the Bolshevik revolution in 1917. The Austrians attacked the French army on December 2, 1805, expecting support from the Russians, to whom it was still November 20th, allowing them 12 more days to get ready.

[1] Not as unlikely as the need to schedule something on 03-Sep-1752!
posted by atbash at 8:39 AM on June 19, 2012 [2 favorites]


For example, if a year is not 365 or 366 days, how long could it be?

In addition to monarchal messing about with the calendar, consider the Hebrew calendar, which is very much in use today. You can read the details yourself, but simplistically because it is a lunar calendar, and lunar months are shorter than solar months, every few years they add an extra month. So you end up with years shorter than 365 days by a bit, and then a year with an extra month pushing it up to 380-something.

Another example of dealing with the time jump in 1752 is things like calculating what day of the week easter fell on in the year 1400. Not always a pressing business need, but calculating holidays is a big deal.
posted by jeffamaphone at 8:49 AM on June 19, 2012


Another fun one - despite the fact that the SI derived unit "day" is defined as 86400 seconds, but solar mean time isn't exactly that. So we have leap seconds; periodically it's agreed to insert an extra second into some specific day, making it 86401 seconds long. In theory some are 86399 as well, but that hasn't ever happened. A leap second hasn't been introduce since January. As a result of this, GPS time and UTC differ currently by 34 seconds. Your GPS probably automatically compensates, but if you haven't gotten a firmware update since last year, it's probably off by a second.
posted by atbash at 8:53 AM on June 19, 2012


jeather: How often do programs written today need to deal with the changing of the calendar in 1752, though? (Sincerely curious here.)

Not often, but more than never.

Off the top of my head, I can think of: Catalogs for museums and (some) libraries, genealogy software, and anything that deals with land deeds, legal cases or old astronomical or meteorological observations. (Note that none of these are things I've personally written software for.)

Another, possibly much larger, category are programs that really don't "need" to deal with it but do anyway just for the geekish pleasure of it. The UNIX date(1) utility arguably falls into this category. And of course, once somebody did it, all subsequent implementations that were supposed to be compatible had to, too. (I'm not sure if POSIX.1 says anything about it...)

The awesome part, of course, is that the calendar didn't just change in September 1752; that change took places in radically different times in different places, and wasn't the only such change.
posted by sourcequench at 9:01 AM on June 19, 2012


> It's more accurate to say that I don't CARE if you write your name using more than one
> character set. I won't accommodate you, because it's not worth it.

I am thinking of the moment Daryl Hannah reveals her true mermaid name, in Splash.
posted by jfuller at 10:10 AM on June 19, 2012


Did you hear the story about JB Smith? (Not his last name.) He had no first or middle names, just the initials J and B. JB had many hassles because of this, because bureaucratic inertia is a slow animal, which demands patient, repetitive explanations about anything unusual. By the time he enlisted into the Army JB had taken to filling out his paperwork like this, to avoid needless confusion: J (only) B (only) Smith.

As a result, he was thereafter known as Jonely Bonely Smith.
posted by mule98J at 10:24 AM on June 19, 2012


Did you hear the story about JB Smith? (Not his last name.) He had no first or middle names, just the initialsletters J and B.

FTFY.

Was Re: Harry S Truman, whose middle name was the letter S.
posted by atbash at 10:51 AM on June 19, 2012


Falsehoods everyone believes about programmers: we always have the final say in dictating specifications and what cases our code will handle.
posted by Zed at 3:50 PM on June 19, 2012 [1 favorite]


jfuller, if she wants to mermaid in my database, she can make up a Unicode representation of it
posted by thelonius at 5:32 PM on June 19, 2012


Jeather asked: How often do programs written today need to deal with the changing of the calendar in 1752, though?

The calender reforms took place on different dates in different countries. Basically, no date between 15th October 1582 and 1st March 1923 is meaningful unless you identify the national calender you're using.

I don't think there's any way to specify this in GEDCOM (the effective standard for exchanging genealogical information) so all the dates that genealogists record may be out by up to thirteen days. The same goes for historical information generally - the 1917 "Red October" revolution in the former USSR actually took place on November 7th, New Style.
posted by Joe in Australia at 7:22 PM on June 19, 2012


As much of an inconvenience as it may seem at the time, anyone who rails against DST has never had to deal with 4:30 a.m. summer sunrises when trying to sleep for another two hours.
posted by DoctorFedora at 12:27 AM on June 20, 2012


Did you hear the story about JB Smith?

I heard that story being told about the student Ronly Bonly Bloggs, by someone who worked in admin at a Canadian university in the 1970s. Clearly this is a longstanding problem!
posted by rory at 1:55 AM on June 20, 2012


As much of an inconvenience as it may seem at the time, anyone who rails against DST has never had to deal with 4:30 a.m. summer sunrises when trying to sleep for another two hours.
Oh, yes, because a 5:30am sunrise is SO much more convenient.
BUY SOME CURTAINS.

(Daylight savings is stupid.)
posted by dickasso at 5:24 AM on June 20, 2012 [2 favorites]


the 1917 "Red October" revolution in the former USSR actually took place on November 7th

Well, it started on November 7th and continued through the night to October 28th of the same year.

Which is kind of awesome when you think about it.
posted by atbash at 7:15 AM on June 20, 2012 [1 favorite]


As much of an inconvenience as it may seem at the time, anyone who rails against DST has never had to deal with 4:30 a.m. summer sunrises when trying to sleep for another two hours.

If I understand you correctly, your argument is: "Bla blah I dont like the way the universe moves."
posted by odinsdream at 7:53 AM on June 20, 2012


If I understand you correctly, your argument is: "Bla blah I dont like the way the universe moves."

Alternately: "blah blah blah I don't like having to change my schedule without changing the time."
posted by atbash at 8:40 AM on June 20, 2012


blah blah blah I don't like being inconvenienced by my lack of bothering to buy blackout curtains

(my schedule won't be changing, because I work outside my home with a set starting time of 8:00 a.m.)
posted by DoctorFedora at 4:07 PM on June 20, 2012


atbash: "the 1917 "Red October" revolution in the former USSR actually took place on November 7th

Well, it started on November 7th and continued through the night to October 28th of the same year.

Which is kind of awesome when you think about it
"

wait THIS IS AWESOME
posted by DoctorFedora at 4:07 PM on June 20, 2012


Well, it started on November 7th and continued through the night to October 28th of the same year.

How do you figure that?
posted by Joe in Australia at 4:29 PM on June 20, 2012


How do you figure that?

I may have that backwards.
posted by atbash at 7:16 PM on June 20, 2012


Eponysterical.
posted by Joe in Australia at 8:52 PM on June 20, 2012 [2 favorites]


Joe in Australia: "Well, it started on November 7th and continued through the night to October 28th of the same year.

How do you figure that?
"

atbash does have it backwards, but it's still cool.

When the revolution began, Russia was in control of the Tsar, and followed the Old Style Julian Calendar, making the day 25 October 1917.

When that day ended, Russia had fallen, the country was effectively under the control of the Communist Party (making it the USSR), and they switched the calendar to the more globally-accepted New Style Gregorian Calendar, where that same day was labeled as 7 November 1917.

So, the revolution lasted from 25 October to 7 November, a period of one day.
posted by IAmBroom at 8:21 AM on June 21, 2012 [2 favorites]


Oops, citation.
posted by IAmBroom at 8:21 AM on June 21, 2012 [1 favorite]


« Older Skepchick vs Psychology Today   |   Read the same three paragraphs... Newer »


This thread has been archived and is closed to new comments



Post