Difference between revisions of "Talk:Implementations"

Revision as of 15:43, 29 May 2008

Shell script broken?

Is it just me, or is the shell script implementation broken? --Psud 08:21, 26 May 2008 (UTC)

Actually, please refer to my comments on the main page discussion. --Psud 12:41, 26 May 2008 (UTC)

I've rewritten the script to incorporate some earlier suggestions I made (they were left on the main page's talk page when the implementations were moved) about portability (you seem to have been bitten by the slicing issue I was worried about). However, you will need to have dc installed no matter what.

Perhaps all the implementation discussion in Talk:Main_Page and its archives should be moved here? I don't even have an account, so I'll leave it to someone who knows what they're doing. --Decklin

Shell version bugs

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

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 DST and 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 17: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)

@@ Line 14: / Line 14: @@
 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
-== Atom feed 30W compliance ==
+== Atom feed 30W-compliance ==
-I just added the atom feed and it seems to be 30W compliant
+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 DST and 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 17:00 UTC.  If anyone does, and has thoughts, hit me up on my talk page.
 : Sincerely, your friendly <s>local</s> (global?) 30W-compliance "expert"... --[[User:Tjtrumpet2323|Tim P]] 15:34, 29 May 2008 (UTC)