Talk:Implementations

Topics on this page which have clearly been handled or resolved can be found in the archives. When archiving a section of this Talk page, please say so in the edit summary here.

Atom feed 30W-compliance

I just added the atom feed and it seems to be 30W-compliant

After some thought, I suppose it would be somewhat compliant. However, in some cases it's too compliant, or compliant in the wrong ways. After 00:00 local time, it automatically switches to the next day, but keeps the old Dow value and rehashes. East of 30W that behavior is desired, since you want to use the previous day's Dow anyway. West of 30W, however, it means we get an "intermediate" hash that's invalid for us. This much has always been a problem with the implementation. Then, sometime after 09:30 ET (I don't know precisely when), it detects the new Dow value and updates the hash... but it does it both west of 30W where it is needed, and east of 30W where it is undesired. In that case, you would get some other "intermediate" using the current Dow with the current day, which isn't what you want. That's a new problem the 30W Rule created.

In summary, it seems to produce invalid hashes between 00:00 (local) and ~09:30 EDT (UTC-4) west of 30W, and between ~09:30 EDT (UTC-4) and 24:00 (local) east of 30W. That is, it's invalid from 00:00-~06:30 in US Pacific Daylight Time (UTC-7), from ~14:30-24:00 British Summer Time (UTC+1) or from ~21:30-24:00 Australia Western Standard Time (UTC+8). I'm not even sure I know what would happen with the feed in New Zealand, where 09:30 USEDT = 01:30 NZST the next day. It'll be even worse come late October/early November, when Australia/NZ switch into DSTand the US switch out... the gap will become 2 hours wider over a couple weeks' time. And of course, these problems are mitigated over weekends, when you have several identical Dow values in a row. Someone should check this out before the weekend, as I'll be busy until Friday 19:00 UTC. If anyone does, and has thoughts, hit me up on my talk page.

Sincerely, your friendly local (global?) 30W-compliance "expert"... --Tim P 15:34, 29 May 2008 (UTC)

I have just updated the feed so it should be 30W compliant. Let me know if it's still a problem. --Xxv 18:03, 30 May 2008 (UTC)

Shell script implementation

While it runs on sh, ksh, and bash now, it still doesn't work on OpenBSD. If GNU date (which has the -d option) is not detected, I assume FreeBSD's -v is available; OpenBSD doesn't appear to have a comparable feature. Could someone test on OS X? No idea what's there (pretty sure they ship with wget, though).

Super brownie points if you can make it fallback to wget *or* fetch in one line so I can delete that stupid usage warning and have it run on FreeBSD out of the box. --Decklin

Could the user at 63.201.144.114 explain what broke? No math is being done in the shell in any case, and nothing added requires the script to be run under GNU bash instead of any POSIX sh. Extra features are nice, if they can only be implemented in the script itself, but that's an entirely separate issue.

iPhone Implementation

Last night I finished a rough implementation of this to the iPhone 2.0 Beta SDK. Right now it uses your current location and date and then does the math, then gives you a map with the destination address along with directions to there from where you are at. This will be even more useful if the next 3G iPhone come with GPS, until then it uses it's less accurate cellular and wifi location tools to locate you. I plan on adding a way to select your date and your desired graticule as well. Eventually I'll also investigate filtering of the results in watery areas. I can't distribute it currently, but as soon as I can I'll make it available. -- Shakedown

Wrong market data for June 2008 in locations east of -30°

The official reference implementation is attempting to fetch the wrong market data for dates in June 2008 for locations east of -30°.

• For 2008-06-01, it attempts to fetch market data for 2008-06-30.
• For 2008-06-02, it attempts to fetch market data for 2008-07-01.
• For 2008-06-29, it attempts to fetch market data for 2008-07-28.
• For 2008-06-30, it attempts to fetch market data for 2008-07-29.
• For 2008-07-01, it attempts to fetch market data for 2008-06-30 (correct).

Locations west of -30°: tested 2008-06-01, which fetches correct data. Not sure of the extent of the issue, more testing needed. - r0d3n7z 18:07, 30 May 2008 (UTC)

Further testing reveals that the problem is not confined to June 2008, but affects all months with less than 31 days for dates after the 30W rule was applied. Hope this helps pinpoint the problem. -- r0d3n7z 18:32, 30 May 2008 (UTC)

It works perfectly fine here, and has been all along since the previous problem was fixed.--80.216.129.239 19:49, 30 May 2008 (UTC)

I'm not seeing this problem? What browser/OS are you using? What does the debugging info show when it gets the wrong data? Zigdon 20:05, 30 May 2008 (UTC)

I am experiencing this across several browsers. Screencaps: FF1.5 FF2 IE6 IE7 Debugging info shows an attempt to fetch market data for an incorrect date. -- r0d3n7z 20:41, 30 May 2008 (UTC)

Tested with the exact same coordinates,dates and browser, and it generates the coordinates perfectly. So must be somethign wrong local. I'll remove the notes from the front page, as clearly several persons have no problems. --80.216.129.239 22:03, 30 May 2008 (UTC)

I've experienced the problem when testing with my 1. own computer on a) my home connection (202.156.183.xxx) and b) via a vpn connection to (155.69.xxx.xxx); 2. a second computer on my home connection; and 3. a remote machine at (155.69.xxx.xxx). Different browsers were used. Browser cache was cleared beforehand. No javascript errors were logged. The problem doesn't seem isolated to any one browser/computer/connection in particular. Any ideas for pinpointing the cause of the problem? -- r0d3n7z 02:24, 31 May 2008 (UTC)

I'm getting it in both Firefox and Opera, both with vpn (130.126.xxx.xxx) and without (83.49.xxx.xxx). Loggie 05:33, 31 May 2008 (UTC)

Originally posted at Talk:Main_Page#Issue_with_the_map...

When I type the date 2008-06-01 into the map, I get the error "Market data is not available for 2008-06-30" However, I can type in 2008-05-32 and also 2008-05-33 and get coordinates. The 34th gives me "Market data is not available for 2008-06-02" (I'm looking at places east of -30°, by the way). Loggie 22:37, 30 May 2008 (UTC)

I get the same problem. BTW the coordinates returned for 2008-05-32 are *not* the correct coordinates for 2008-06-01, since it uses wrong date (2008-05-32) in the hash. Not sure if you realize this or are just pointing out more data -- at first I thought you had found a tricky workaround :)

Another observation, the page is also looking for DJI data on 2008-07-01, when I type in 2008-06-02, this is rather odd. --124.168.225.106 02:42, 31 May 2008 (UTC)

Originally posted at Template_talk:Expeditions/2008-05-31#end_of_the_month...

When looking for hash locations through Sunday and Monday, I found the reference implementation is looking for DJI data on 2008-06-30, suggesting that months are not being handled correctly. Can someone confirm?

This is clearly not a localized problem. Re-posting the notes on the front page. -- r0d3n7z 03:11, 31 May 2008 (UTC)

UPDATE - I put a workaround in place aroudn this weird problem, but I still don't actually understand it. Zigdon 07:33, 31 May 2008 (UTC)

Now suddenly I'm experiencing the exact same problem, after it working fine before. Don't know if the workaround caused this problem for me or if it's just suddenly decided to show up. --80.216.129.239 10:55, 31 May 2008 (UTC)

The workaround fixed the problem for me. Debugging info will print something like "YOU ARE INSANE. 6!=5!!! TRYING TO PLAY ALONG." when the workaround kicks in (in my case, that's any date in Feb/Apr/Jun/Sep/Nov after May 2008). Please check the debugging info to confirm if the workaround is active or inactive when you experience the problem. Either way, this is a really strange bug! -- r0d3n7z 12:48, 31 May 2008 (UTC)

It's working for me now too. Loggie 12:55, 31 May 2008 (UTC)

@Zigdon: I have a bit of a hunch, as I was seeing some similar problems in templates on the wiki today (UTC)... I'll see if I can't take a stab at it... --Tim P 16:39, 31 May 2008 (UTC)

Just take a look at http://irc.peeron.com/xkcd/map/xkcd.js, search for 'YOU ARE INSANE'. Zigdon 16:44, 31 May 2008 (UTC)

I discovered that link accidentally just minutes after posting that. No luck yet. It really is insane. --Tim P 17:21, 31 May 2008 (UTC)

I had the same very strange problem. At the moment, the workaround kicks in when I use the tool. This is what it looks like. Using FF 2.0.0.14 as can be seen in the screenshot. I'm online using Eduroam (http://www.eduroam.org) at K.U.Leuven (http://eduroam.kuleuven.be) with my laptop, running WinXPpro. If you need any other info, just ask. Let us know when the cause of this wacky bug has been found! --Rex 18:55, 31 May 2008 (UTC)

SOLUTION numbers need to be cast as int's before you do math on them: parseInt(datecomp[0])-1, etc. --CWolves 01:34, 1 June 2008 (UTC)

I had the feeling it had to do with numbers being read in octal or math not being applied correctly to the months. --Tim P 01:50, 1 June 2008 (UTC)

This makes sense (and that's for coming to my rescue :). That said, I don't think it fixed the problem? Zigdon 02:30, 1 June 2008 (UTC)

FIXED Ah ha - I think I got it now. JS didn't like me setting the month and day in two calls. I can only assume that it's because the date which is being set (intermittently) is invalid. Which is why the problem started happening when the *current* date was the 31st. Calling setMonth(month, day) seems to fix it. If anyone is still getting the 'YOU ARE INSANE' message in the debugging (when feeding it a valid date), please let me know. Zigdon 02:38, 1 June 2008 (UTC)

Zero-padding of date east of 30W

Fix one problem, creates another. East of 30W, dates going into the MD5 hash are not properly zero-padded. E.g.,

xkcd.js version $Id: xkcd.js 202 2008-06-01 02:27:19Z dan $
After 30W adjustment, date is 2008-05-31
Market open on 2008-05-31 = 12647.36
MD5(2008-6-1-12647.36): 980b032a1ab1be848faf740c9882c545
Split: 980b032a1ab1be84, 8faf740c9882c545
...
etc.

The MD5 function should be hashing 2008-06-01-12647.36 instead. I think this is just a simple side-effect of the last fix, but it's wrong for all dates from 27 May 2008 in all locales east of 30W, so this is a major issue. At least we're not "insane" anymore. --Tim P 03:07, 1 June 2008 (UTC) FIXED - This has been fixed. --Tim P 04:29, 1 June 2008 (UTC)

The last 2 problems being fixed, I tested every date from 29/05 up to and including 02/06: no more "insane" and the coordinates correctly match those on the wiki. --Rex 11:44, 1 June 2008 (UTC)

Good. I'm glad. --Tim P 14:54, 1 June 2008 (UTC)

Flickr?

So, there're likely a bunch of media-sharing sites out there that allow users to tag content; and some subset of those will have geohashing users. I've added a link to Flickr's RSS feed for "photos tagged geohashing" to this page, but I'm not entirely convinced it belongs here. Please feel free to move (or simply remove, I supose) it. --Tapin 03:07, 2 June 2008 (UTC)