Vid's Space

Hello! You are visitor number 86289! I may be a bit narcissistic, but I don't quite want to talk about myself for pages and pages on my website anymore.  I could, but that might be a bit depressing.  Meh, at least I have a job.

Suffice it to say I'm a pansexual nudist roadgeek with issues including but not limited to depression, selective eating disorder, and possibly Asperger's syndrome.  But again, this page isn't about me.  Instead, it's my space for random thoughts which I hope you'll find interesting or amusing. 

By the way, if you don't like the fonts or colors on my website, now you can override them using the Style Chooser!  As for other improvements to this site, I really need to redo the guestbook, get the counter/greeter system to work how I originally intended, and oh yeah, get in the habit of adding content more often…

Random Quotes

I hope you'll find the following quote amusing and/or thought-provoking.

“The problem is that God gives men a brain and a penis, and only enough blood to run one at a time.”

— Robin Williams

A new quote is randomly selected three times each day. For your convenience, here's a permanent link to this quote.

Cool Story, Bro!

Here you'll find brief anecdotes which usually are worth the time spent reading them.

New items will be selected in 2.8 days.

Self-Referential Playlist

I was mowing the lawn the other day, listening to 80s music on my smartphone. In the song "Everybody Walk the Dinosaur", I noted a lyric that said something about watching "Miami Vice". As if to say "That's a good idea," my media player chose the "Miami Vice" theme song to play next.

Freudian Spoonerism

This one time, during a discussion about how much damage would occur at different distances from a nuclear blast in downtown Columbus, I meant to say West Broad Street, but the sounds got a little mixed up in my head, and I would have said Breast Wad Street had I not caught myself halfway through the first word.

Police Chase

One time, I was driving home from somewhere in Columbus. On the freeway, I had just moved out of the left-most lane when two vehicles passed me at high speed on the left. When I got home, my older brother was there, and I told him I though I'd seen a high-speed police chase. He said it was probably just a couple of idiots racing.

“Well in that case, the guy in the police car was losing!”

More Cool Story, Bro!

Passing Thoughts

This is the opinion section of my site. If I have something to say to a general audience that won't fit in a tweet, it'll probably end up here.

New items will be selected in 18.8 hours.

Don't say “Standard Time” Unless You Mean It

I have seen, many times, people announcing some event on the Internet in terms of EST (Eastern Standard Time) or, slightly less often, PST. In the winter, there's no practical problem with that, but for slightly more than half of the year, this terminology comes with a significant “gotcha”. See, chances are, whoever posted the announcement actually means not “Eastern Standard Time” but “the time in New York City” – or, instead of “Pacific Standard Time,” they mean “The time in Los Angeles.” The problem is that, from March to November, New York City doesn't follow Eastern Standard Time; it follows Eastern Daylight-saving Time! When we change our clocks in the spring and fall, Standard Time doesn't change; rather, we switch between it and Daylight-saving Time. So in the summer, while Eastern Standard Time still exists, nobody follows it (except for the west coast of South America, but they surely don't call it that). Most of Indiana did until 2007, but not anymore. And while Phoenix and Denver are both in Mountain Time Zone, only one of them is actually on Mountain Standard Time in the summer.

There are a few solutions. First and best, you could say EDT when Daylight-saving Time is in effect, and EST otherwise. Or, especially when referring to geographic areas and not actual times, say ETZ. The laziest way to specify what time zone you're talking about correctly, especially if you don't know whether DST is (or will be) in effect at the specified time, is to simply say ET if you mean the time in New York, and PT if you mean the time in Los Angeles. (And of course CT for Chicago, and MT for Denver…) I believe that's what CNN does.

The bottom line is this: If you are based in New York and announce some kind of deadline as “11:59PM EST on June 30”, and someone submits something when your clock says 12:45 AM July 1st, that submission is not late, because on Eastern Standard Time, it's still only 11:45 PM. Sure, you could argue about it, but it's just better to say what you mean in the first place and avoid any confusion entirely.

Leap Day Reform for the Digital Age

Many date-handling tasks computers routinely face — such as translating dates between human-readable and internal formats, or just determining what day of the week a given day falls on — requires code that converts a year/month/day combination to a simple number of days since some reference date, or vice versa. Anyone who has had to write such computer code knows that our Gregorian Calendar isn't very convenient for computers.

For example, one fairly obvious method would be to start with the day of the month, then add a number to that (using the month as an index into a lookup table) to obtain how many days since the start of the year. But then, if it's a leap year and the month is greater than February, the program has to add one. Finally, to this number, the program adds 365 times the year (relative to the reference year) plus the number of leap years after the reference year and before the year of the date being evaluated. Now consider the Gregorian Calendar's rules on leap years: every year that's a multiple of four is a leap year, except years that are a multiple of one hundred are not leap years, unless the year is a multiple of four hundred, in which case it is indeed a leap year.

The first thing about all that I'd like to simplify is how, for any month March and later, the number of days since the start of the year for a given date depends on whether or not the current year is a leap year. This consideration can be made unnecessary by moving leap days to the end of the year. In the Digital Age Calendar, February's length is fixed at 29 days, and December's is 30 days, or 31 in leap years.

The next thing I'd like to simplify is the pattern of leap years. I'll keep the general pattern of having a leap year every multiple of four, because it's already convenient for computers. Scrapping the one-hundred-year and four-hundred-year parts of the pattern, we'd wind up having leap years slightly too often. So I calculated the ideal interval between skipping leap years, and it turns out to be almost exactly 128 years. That's surprisingly convenient for a computer! In the Digital Age Calendar, leap years are those preceding the multiples of four, but not those preceding multiples of 128. (The choice to have leap years before multiples of four is to further simplify computer calculation. The alternative would be to somehow insert a leap day at the beginning of the year, and I don't think people would adapt so well to having a 0th of January.) Anyway, the resulting pattern of having 31 leap days in a 128-year cycle matches the Earth's orbit considerably better than the Gregorian Calendar's pattern of 97 leap days in a 400-year cycle.

So here's some simple computer code to convert from a date to a number of days. In this example, the reference date is December 31, 1919 in both the Digital Age and Gregorian calendars.

const int MOffset[12] = {0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335};

int SequenceDay(int Year, int Month, int Day) {
	Year -= 1920;
	return (Year * 365) + (Year >> 2) - (Year >> 7) + MOffset[Month + 1] + Day;

void SplitYMD(int Seq, int &Year, int &Month, int &Day) {
	int Cycles, Quads;
	Seq -= 1;
	Cycles = Seq / 46751; //integer division, rounded towards −∞
	Seq += Cycles;
	Quads = Seq / 1461;
	Seq -= Quads * 1461;
	Year = Seq / 365;
	Seq -= Year * 365;
	Year += Quads * 4;
	Month = 11;
	while (MOffset[Month] > Seq) {
		Month -= 1;
	Day = Seq - MOffset[Month] + 1;
	Month += 1;
	Year += 1920;

While this may look a lot like C++, consider it to be pseudocode — especially if you find syntax errors. For the Gregorian Calendar, there would certainly have to be more ifs and modulos. Also, feel free to substitute your favorite search algorithm for my while loop. (I'd personally implement a binary search, but the linear search makes clearer pseudocode.)

Of course, any time a new calendar is adopted, there will be some conversion issues, particularly if the adoption isn't universal. Still, the difference would only be of one day, and only for 60 days each year, three of every four years. Seven eighths of the time, the calendars match. That is, until 2048, at which point the calendars will begin to disagree every day until 2100…

Besides the simple fact that people don't like change, I don't see why this calendar couldn't be adopted. Using the slightest amount of care in selecting the transition date, it's easy to make the transition without a noticeable jump in the date, as happened in the switch from the Julian Calendar. They did it back then, and this change would be even less of a bother. Except, perhaps, for the millions of embedded systems that can't easily be updated. How's that for irony?

Okay, I realize that the only practical problem solved by this new calendar is in writing code, and once the code is written, it hardly needs to be written again. Furthermore, any performance gains resulting from simpler code are irrelevant considering modern computing power. Still, I find this Digital Age Calendar to be simply more elegant and logical. Can't that be reason enough to switch?

More Passing Thoughts

Cool People

Cool Famous People

Here are, in no particular order, some of my favorite people from movies and TV:

Cool Obscure People

Here are, in no particular order, some of my favorite people of whom you may not have heard:

Best of my LJ

You know how radio shows often run "best of" shows during the weekends or when the stars are on vacation?  Well, I haven't posted to my LiveJournal much recently, but there are some good nuggets from the past I thought I might share here.