Wedge

Only for readability later on. Using 3600 will be faster than using 60*60, but 60*60 is more readable. Unless we're talking an insanely busy site it doesn't matter (and if we are, there are bigger things to worry about than that anyway)

I do get so confused in trying to decipher the mindfuck that is time and date in PHP.

I'm confused why you're putting in time() + 3600. gmstrftime as PHP's manual says wants two parameters - the format you want to display and the time you want to display in that format, putting in time() + 3600 is just going to confuse it (and it complains)

The description seems to indicate that it would actually deal with the offset itself (since setlocale should be providing it), which would suggest simply:

Failing that, the more naive but workable solution (though won't take into account DST)

Well, this is the thing, it's security by obscurity, and a measure I'm prepared to accept because it isn't a measure that is secure all on its own - but as a facet of a more complex system.

If it works, it's probably correct... ;)

I'm not going to get into the meat of things here, because there's a lot of things that this impacts on, but I will take care of the issue relating to 3NF.

There are times and places that normalised data can have performance concerns. (And really, 3NF is tame. Wait until you start dealing with 5NF. :niark:) Like everything else, that is.

Now, a lot of my concern about normalising everything is that you end up generating far more rows in a resultset than you need or you start getting more queries, and for information you're loading at certain times, it's going to get hideous.

I actually have an example in SMF for this: board level moderators. They're stored in their own table, and during the board index gathering query, they're actually pulled via join into the main query. Now, on a forum without any board level moderators, it's not a problem. But if you have one board with 3 moderators, that board is returned three times, once for each moderator, which has to be cleaned up in PHP, and that accounts for some of the overhead attached to the board index stuff (which is, indirectly, one of the reasons the sub-board-of-a-sub-board problem occurs).

In that particular case, I'd almost argue that having board moderators would almost be better handled as a comma-separated value stored inline in the board table, precisely because there aren't many of them in most cases.

Getting back to the concern here, separating out friends to another table will give you the proper asynchronous structure you want. But it means that loading the list of friends up front is not cheap, because it means either overloading the first query where mem.* is loaded (which for any number of friends is non trivial), or we add a new query at that point, or we push it into a cache.

That said, we can consider a few alternatives... where exactly do we need to know and care about whether a given user is a friend of ours? Well, for the users online area in the footer, certainly, but with an asynch table we can actually do a join from *that* query and figure it out that way. For the PM area we can do a query as needed there, and so on.

Like everything else, it's a change, but it can bring other changes to balance it out.

Therein lies part of the problem: a user name and general location are not yet considered to be personal information. I have no doubt that usernames and email addresses will become personal information in the future, but at this time they are not within the definition given.

Exact location is a bit different, because it could be a matter of public record. For example, if I were to put my location in, it could be claimed that my name and address are matters of public record (voter's roll, domain name WHOIS), so it's not even that simple.This is partly why I never enforce a ban as a true 'ban' in the SMF sense, I do it by a 100% warning (since that also saves certain performance matters), and I suspect we can build that in to the changes to the ban system, since the ban system as it stands needs to be withdrawn.

It gets more complicated, though... what happens if a ban is enacted accidentally against a user who wishes to update or remove their information? Say there's a ban on host which locks out so many more users? Yes, I'd argue there's a problem there, but I don't see how, viably, it's possible to solve them at this time.Even that's complicated. What happens if those PMs formed part of a conversation? How does one justify removing them from someone who has received said messages?

What happens if the ban is later removed? Or was put in place by accident?Agreed, there is no known site that has fallen foul of DPA violations (in no small part because the content held by a forum is on the fringe of what is considered to be personal information), but with the cookie law, the ICO is signalling a clear intent to pursue privacy and related matters.

And that's the thing, ultimately, I have no idea whether the ICO would check for violations or not. But while I as a site owner may take one stance, I have to consider the implications for Wedge as a platform too.

Last night, just out of curiosity, I went looking for it on phpBB, because phpBB has at least one UK developer (and their primarily language is 'British English'), and I will also look at what XenForo is doing, though I haven't yet. What intrigued me is that there's a distinct 'we don't think the ICO will pursue it' attitude, it's almost like SMF's stance - 'we don't think anything will be done so we don't have to worry about it', as such they're not planning on doing anything about it.

Now, I personally do not believe we're going to see a rash of complaints or enforcement actions, but that's my personal opinion, not with my 'platform steward' hat on. And I have to consider it a viable threat until I see some evidence to the contrary with that in mind.

]SMF and Wedge have ambiguous behaviour here.

For guests who do not register and have never registered nor never logged in, they get a session cookie, which is a true session cookie - it expires when they close their browser. This is the infamous PHPSESSID cookie, of course.

Logging in, you do get to specify how long you're logged in for. 'Forever' is not really forever, either, it's actually 3 years. But the problem attached is that the PHPSESSID cookie is also held for the same time, but as far as I'm concerned this is actually a bug, because there is no need to keep the session cookie when a proper cookie is established.This is a browser issue and that something I'd have to argue is neither our concern nor our problem. Indicating that a cookie lasts until the browser closes (which in modern parlance is theoretically when the tab is closed, not when the browser itself is closed, as I understand it) is a sign of good faith - it's not our place to police that. We indicate the lifetime of a cookie, if the browser doesn't adhere that isn't actually our fault.

Yup, it is useless, unless you want to directly use $date itself into the echo statement.

http://php.net/manual/en/function.date.php: