Wedge

Having issues with loadLanguage.

Basically, I want to call that code only once... But how do I determine that I'm in a 'first loop' and should skip? I could test for $fatal, because it's only set for Settings and ThemeStrings (which IIRC are deprecated...? At least ThemeStrings?!), but it feels like a bit of a hack... if (!$fatal && $template_name === 'index')... Would that be okay?

:edit: if ($fatal), sorry.

Okay, I added a new param, $fallback, which should make it less of a hack now... ;)
It seems to be working, too. I added the code in the code block that was already dealing with setlocale, meaning it saves time because in fallback mode it would execute it twice.

And I think that it's safe enough to assume that all language files will have both $txt['time_format'] and $txt['day_suffix'] set (even to the same value as English is okay...)

Alrighty...

- There's only one timezone that isn't based on increments of 30mn, and it's Katmandu, Nepal. I don't think that Nepal is worth bothering too much about proper time offsets.
So, I've done some testing with this mini-cache... Turns out that it can save up to 50% performance when applied to topics with chat-like conversations. However, in other situations it doesn't save anything (oddly, I could even reproduce a case where it made everything slightly slower...)
Still, given that we're mostly within a one-millisecond performance optimization, maybe it just isn't worth getting into a fight with Nepal. :P

- time format isn't obsolete. I think you confused it with time offset...?

- using an array is a good suggestion indeed. Here's wondering, though, if it'd be worth it in terms of PHP parsing... I know that for instance, if you add an unserialize() call within a language file, or any file, it actually loads much faster than the regular array notation. Also... Where should we build support for arrays? In number_context() directly? Or in the first call to timeformat()?

Again *sigh*:

- don't post full paths in your error logs...
- if anything happens and it doesn't happen a minute later, then you probably loaded a page while I was working on it. (In this case, I was working on the pretty URL code, meaning I had to reupload the Subs-Template.php file which also contains the wetem class, so during the few seconds when it was being uploaded, it was no longer accessible to the server itself. Hence the error message.)

This is the kind of thing that happens when you're on a forum that's being worked on in real time. It's the downside. The upside, of course, is that Wedge will no longer 'hide' any of its features ;)

Hmm it's complicated...I was in UTC Dublin by default (i.e. not having set a timezone...), which is logical since if no timezone is set, Wedge will put "selected" on that entry.
So I changed my time format but forgot to also set my timezone, and as a result my forum pages were all showing dates that were late by one hour. :(
Meaning that Wedge should try and determine which timezone to use by default.UTC+1 - Amsterdam, Rome, Berlin, Vienna...
UTC+1 - Brussels, Copenhagen, Madrid, Paris...

If Copenhagen, which is further east compared to Amsterdam, is in the same timezone as Madrid which is further west to it, it probably means that they don't share the same 'rules' when it comes to daylight savings etc... Maybe they're set on a different (but close enough) day, I don't know.
What I know though, is that Wedge is 50% French and I demand a Paris timezone in the list :lol:After a few days of use, I decided that I'd rather have a (very slightly) slower Wedge that does dates correctly, unlike other forum systems. :)

I was thinking of something, can you tell me what you think...?
So, we have a UNIX timestamp to begin with. Doing $timestamp - ($timestamp % 1800) will round it to the half-hour, and since no timezones exist that require a 15mn granularity, it means that all dates between 14:00 and 14:30 (for instance) will be on the same day (whatever the server time), and will thus use the same code path.

So, I'm suggesting this: store the rounded time in a static array, and if it's set, get the format from it. Otherwise, just calculate the format and then store it in the index as the rounded time.
Although it won't be helpful everywhere, just imagine a topic page... If some people start discussing like they're on a chat, you can end up caching the time format for nearly every single date retrieved from that page.

What do you think...? Does it work as a concept?Yeah, I remember that, it was a good idea :)

Didn't think we'd fall into conspiracy theories so quickly :P

Oh yes! I forgot it's only here for now...