requinix

Why aren't you using a DATE or DATETIME column?

It hasn't changed. Generally, it's a good idea to have . on your include path. Not that. That's still relative to the CWD (and I tested this). The fact that it eventually searches the current file's directory regardless of the include_path is new.

You did remember to instantiate the class and call the function, right? $one = new One(); $one->main();

Huh. If you could see me now I'd have egg on my face It seems they've changed the behavior of include() and its friends to what everybody's expected they did. Now it does search the current file's directory at some point in the process and after it tries the CWD. In my defense I know I'm correct... but apparently for previous versions of PHP before 5.3.6 (what I have on-hand to test with). And going through the user comments, for starters, reaffirms that it's changed in the relatively recent past. In other words, DISREGARD THAT I SUCK EGGS. But it's still best to use absolute paths. That hasn't changed.

I've made it my personal mission to point out this issue: It's not relative to the file that's doing the requiring. It's relative to the current working directory. Generally it is the same directory as the first file that was executed, but not necessarily. Generally it doesn't change, but not necessarily.

Almost. The first is an absolute location and will always work. The second is relative and will only work if the current working directory is the same directory running that code (and containing config.php).

I love delving into these sorts of problems and I think I know what it is so I figure I might as well share: (this is all according to the PHP 5.4.0 source code but I'm sure the relevant bits haven't changed in a while) (note that ksort() and sort() and friends work exactly the same way except for what bits they're looking at - ksort() looks at keys while sort() looks at values) When built-in sorting functions do a normal sort they run a comparison function against pairs of values - exactly how the u*sort()s work with your own comparison function. The default function (sort_flags=SORT_REGULAR) is the first half of the issue. It has a long list of actions it takes based on the types of the arguments. For instance, if the two are long* then it compares them as longs, and if one's double* while the other is long then it compares them as doubles. There is nothing that compares strings versus longs so that case falls into the default action. Said default is to cast both to numbers (either long or double as needed) and compare that way. The second half of the issue is how PHP (Zend, actually) does sorting: quicksort**. Basically the list is sorted into two parts where the first is all the pivot. The pivot then gets placed right in the middle. The two parts are sorted the same way recursively until the base case where there are only a couple items. Here's where it gets unpredictable. When the array consists of mixed strings and numbers the comparisons may contradict each other. The simplest example is an array of three items: array("ABC", 123, "789") There are three different comparisons: "ABC" 123 "789" Thus a contradiction: ABC Quite reasonable, quicksort does not look for contradictions like this because it assumes that the comparison function cannot possibly create any. Once compared it doesn't go back over the list, thus there are no infinite loops of constantly moving list items around as the function dictates. The end result is undefined behavior because the same array items in varying orders will create different results. [code]"ABC", 123, "789" => "ABC", 123, "789" "ABC", "789", 123 => 123, "789", "ABC 123, "ABC", "789" => "789", "ABC", 123

You might be missing out on the A in AJAX. ...Uh, the first one. You can't do anything with the result unless you put it in that success function. If you try anywhere else you're going to get a null/undefined because the AJAX hasn't happened yet. Pretend that it takes 5 minutes for anything to happen: you can't get the answer immediately so you have to put in some function that'll execute later (ie, in five minutes) when it does have the answer. Meanwhile you just wait for it to come back.

Known bug. But it's not about the plus - it has to do partly with the "0" key (try sorting without it). ksort() has problems of the "undefined behavior" type when you mix integer/integer-string and string keys* but there's more to it than just that. You can work around it by passing in a sort flag. ksort($array, SORT_STRING); * Array keys that are integer strings, like "0" and "123", are silently converted to actual numeric keys (0 and 123). var_dump(array_keys(array("0" => "zero"))); // [0]=>int(0)

Then... asking your hosting provider how you can change permissions on files. Or use a database instead of a file.

Use FTP or whatever you have to create that file yourself. Put a 0 in it. Then change its permissions (chmod) to 0666 (=readable and writable for everybody) and try your script again.

$var = fopen('$myfile,\'r+\''); Reconsider that.

There might be a bottleneck downloading the file from FTP. Can you tell how fast that connection is? Is it about 8KB/s? When you're downloading the file yourself, does the speed vary or is it constant?

Probably because the $time->toAtom() function does it that way intentionally. Look at its code. Let me reiterate: there's nothing wrong with what it's doing (provided it's not doing anything wrong). Whether it shows noon UTC or 2pm UTC+2 doesn't really matter.

This is okay but this is not

Then unset it in the php.ini and let it pick up the timezone from the computer. If that doesn't work (or I'm just misunderstanding you) then set date.timezone according to this list (basically, pick whichever city is closest and in the same timezone with the same DST rules).

Huh. How about the timezone for the computer?

Too bad it won't work properly on input like This is okay but this is not

Your various img and script srcs, link and whatever else hrefs all need to be absolute. Right now they have relative URLs like Or maybe ../path. Whatever. Those are all relative paths and they're relative to the current page. Go into enough subdirectories and the paths will break. Change them to include a leading slash: That way they'll always come out of the same place regardless of the current page.

I'm also really tired so my normal inhibitions are... well... not there. Stuff with forms, assigning stuff that doesn't exist, !$x versus empty($x), it's all very confusing and can take a while to get a handle on. The code bits look different and represent two different things, it's just that in this case they both arrive at the same results.

Probably nothing. What does echo date("r"); output? If it uses the right timezone then you have to adjust whatever $time->toAtom is.

That computation is fine. var P27_max_convert = ((parseFloat(P27_max) * parseFloat(1000)) / parseFloat(0.00) / parseFloat(12)); This one isn't. (And if you're wondering, isNaN() does not check for infinity.)

"Z" represents UTC and is valid shorthand for its timezone. As long as the time is correct for UTC (it was converted from the local timezone properly) you're fine and there's nothing wrong.

Just feel like making a bit of a correction: 1. They do not "exist" if they weren't submitted (eg, the form wasn't submitted). That's because $_POST[foo] doesn't exist, resolves to null, gets assigned to whatever variables, which then (a) don't "exist" because they have a null value, thus (b) aren't isset(), and so © are empty(). They only exist if they were submitted with any value at all, but the best part is doing !$foo will create problems when it shouldn't - like if $foo="0". That's true for empty() too actually. 2. OP has to do empty() on what's in $_POST or else PHP can/will fire undefined offset warnings during the assignments. 3. The two bits of quoted code are identical. They do exactly the same thing. There is no difference.

You can't give a value to a SELECT. Mark the appropriate option as the default, so class17select="selected='selected'".