meeting-scheduling software

[cellio]

I just used MeetingMaker to schedule a weekly meeting. It requires that you specify an end date -- or you can just check "ongoing". Doing the latter causes it to fill in an end date of 12/31/2039. (Which is a Saturday, just in case you were wondering. My recurring meeting is on Tuesday, so one could argue that it should have set the end date differently.)

It quickly reported the two dates this year that some attendee isn't available. This made me wonder whether it was, in fact, searching a sparse calendar all the way through 2039, in which case it gets points for speed but maybe not for appropriateness, or whether it has some built-in limit for how far ahead it will search for conflicts.

By the way, the odds are very good that the room in which my 34-year recurring meeting occurs will cease to be available later this year.

Comments

[metahacker.livejournal.com]

Huh. Now, admittedly, modern computers are REALLY fast, so a search through 10,000 days like that would be darn fast. But I'm betting it has a list of their events, rather than hashed by date, so it's really just doing an n^2 compare with all their events and seeing if they are ever on a Tuesday. Since most things either have a handful of dates, or recur on particular DoWs, this should be fast...but things like "every 15th" could get trickier.

You could test it out by scheduling something that'll only conflict once in a blue moon...say, on Tuesdays that are Feb 29th...

I also like the fact that evidently the Windows universe ends on 2039. Hey, at least it's a year later than Unix, right? Somehow I think my retirement may be filled with Y2K38 bug fixing..."What, you know a *programming language*, old feller?"

[goldsquare.livejournal.com]

I once wrote a bug against some software that had a Y2K hug for 2438 or thereabouts. The "fix" was to move change the algorithm slightly and have the bug resurface in 3000-something.

Try as I might to get people to address it, I always got the answer of "we'll fix it then".

[dagonell.livejournal.com]

At my old job, I was installing 'fixes' that had been designed by others. One of the versions made the bug resurface in 2020. Any questions I had about this were met with the flip comment "Think of it as job security."

[goldsquare.livejournal.com]

I've seen the reaction myself.

But if you look at the dates on my bug, it's Job Immortality. Which would be fine if it worked that way. :-)

[cellio]

But if you look at the dates on my bug, it's Job Immortality. Which would be fine if it worked that way. :-)

Yeah, if only that worked: "gee, I'll insert a bug in the leap-year code that introduces a problem every 4000 years, and wait for them to call me to fix it!".

[dr-zrfq.livejournal.com]

With a very simple change, the Unix universe can end in 2105 instead of 2038. (Make "time_t" an UNsigned integer.)

What's more, if you implement that simple change, then at the fateful time on the fateful day in 2105, it will suddenly become 1 January 1970.

[cellio]

I'll bet people will ignore the problem until late in 2037 and then make exactly that fix -- but at high contractor costs because they waited. Some people didn't learn from Y2K.

Apropos of nothing, the prayer book my synagogue uses for the high holy days has a Y5.8K problem. The current year is 5765, so they'll probably propegate a new version before it becomes relevant. (The liturgy for Rosh Hashana, the new year, includes a place where you insert the date (in Hebrew). They helpfully filled in the first two digits.)