Wedge

Public area => The Pub => Features => Topic started by: Nao on April 3rd, 2012, 01:56 PM

Title: timeformat annoys me...
Post by: Nao on April 3rd, 2012, 01:56 PM
Here are a few things I'm looking into...

- Looks like passing an %e to strftime() will return " 1" in case you're on the first of a month, instead of "1". I have no idea why PHP is adding the leading space. It's okay in most cases, but in French the number comes first, so if you show the date (like this), you will get ( 1 avril) instead of (1 avril). (Well, actually it should say "(1er avril)" to be proper French, and that's actually in the Noisen codebase, but I never got around to find a *QUICK* way to do it that would also be usable by other languages, rather than just French....)

- Speaking of timeformat(), it's called every time a date is calculated on the page. Meaning it's called a lot on most pages...
I was thinking, wouldn't there be a way to simply cache *for the duration of the page load* (e.g. a static variable) as much data as we can...? Because redoing the calculations is a bit silly if you ask me. Heck, we could even store the last calculated date, determine whether it has the same characteristics, and refuse its time format...

- Generally speaking, timeformat() is a real mess to begin with. It has so much code... I'm pretty sure there are simpler ways to implement this.

- Pete, what about your changes to the admin area...? I've been postponing the moving of admin files to their own folders because you told me you had something on the backburner... (Not that it's urgent or anything, though.)
Title: Re: timeformat annoys me...
Post by: Pandos on April 3rd, 2012, 02:12 PM
Did you try it with %-e ?
The "-" option requests no padding.
Title: Re: timeformat annoys me...
Post by: Nao on April 3rd, 2012, 04:23 PM
Wouldn't work for users who already have a timeformat set up would it..?
Title: Re: timeformat annoys me...
Post by: Arantor on April 3rd, 2012, 04:38 PM
What calculations, exactly, can you cache between calls for the life of the page?

In a typical page, you're calling it ~20 times, each with a different time each time. It's also potentially different for different users, further eroding the value of cache, no?
Title: Re: timeformat annoys me...
Post by: Nao on April 3rd, 2012, 06:08 PM
Quote from Arantor on April 3rd, 2012, 04:38 PM
What calculations, exactly, can you cache between calls for the life of the page?

In a typical page, you're calling it ~20 times, each with a different time each time.
Except there are only two different time formats (or so), the regular one and the Today/Yesterday shortcut... (And the year-free version, too... Hmm.)
Quote
It's also potentially different for different users, further eroding the value of cache, no?
Life of the page, as we said. So it's once per user...
Posted: April 3rd, 2012, 06:08 PM

What do you think about the %e issue, Pete?
Title: Re: timeformat annoys me...
Post by: Arantor on April 3rd, 2012, 06:21 PM
There are multiple different formats, sure, and to achieve one, timeformat is even re-called by itself to make that happen.

Now, I realise that there's a life-of-page duration, but I'm not clear what it is you can actually calculate and reuse for the life of page. I just can't think of anything right now :(
Title: Re: timeformat annoys me...
Post by: Nao on April 3rd, 2012, 09:22 PM
What I was thinking was calculating the minimum date to have a full date, not a shortcut. Then the minimal date to have a year added. That's two milestones. We could cache date formats if a date is found to be in that threshold.

Maybe I'm wrong though...
Title: Re: timeformat annoys me...
Post by: Arantor on April 3rd, 2012, 09:31 PM
Hmm, I suppose you could do that.

The thing is timeformat does get called a lot but at the same time, it's still not the most expensive of the function calls, in the scheme of things, parse_bbc is of course the monster, but even ignoring that, timeformat is quite a way done the list in terms of time used.

But it is a reasonably low hanging fruit to optimise, so if you want to tackle it, by all means :)
Title: Re: timeformat annoys me...
Post by: Nao on April 3rd, 2012, 10:45 PM
I couldn't do much to optimize, in the end... Until I found out that non-English installs may benefit from just skipping a replacement loop that makes the time string go through multiple strftime calls :)

Made 10.000 loops and the new version executed in .12s in average, versus .3s for the 'full' version.
Of course it's VERY fast in both cases... You're right, I probably wasted my time lol.
Title: Re: timeformat annoys me...
Post by: Arantor on April 3rd, 2012, 11:03 PM
It's another case of Amdahl's Law, but ultimately it's every case where performance can be improved, it's worth doing, provided that it doesn't prevent other optimisations being possible.
Title: Re: timeformat annoys me...
Post by: Nao on April 4th, 2012, 10:57 AM
Yup.
BTW the SVN version is buggy (it no longer supports Today/Yesterday), it's just a matter of one line to move down, I fixed it here yesterday but haven't yet got around to committing it...
Title: Re: timeformat annoys me...
Post by: Nao on April 5th, 2012, 10:27 AM
Quote from Pandos on April 3rd, 2012, 02:12 PM
Did you try it with %-e ?
The "-" option requests no padding.
I'm having trouble with %-e.
I updated the documentation to "blindly" say to use %-e instead of %e, and to use it by default at install time as well...
However, I can't for the life of me find any frigging documentation about this 'hidden feature' of strftime().
This is annoying to me because for what it's worth, it could very well be something that only works on Apache 2, or Windows, or whatever.

Right now I'm considering returning a trimmed string instead of doing it at strftime().
I don't think that trim() is a very expensive function, and it should solve problems when using parenthesis around the date.
What do you think, guys..?
Title: Re: timeformat annoys me...
Post by: Arantor on April 5th, 2012, 10:44 AM
%e doesn't work om Windows anyway, I doubt %-e would either, and I've never heard of - to strip padding.

trim isn't expensive, and AFAIK it isn't that expensive if you substitute another character, in this case I'm thinking ltrim() on %d rather than %e and pass in '0' as the second parameter so it left-trims leading zeros. It's likely to be as fast as using trim() would be with the bonus that it'll work consistently on all platforms, something that doesn't occur with %e (there are people out there who do use Windows hosting in production!)
Title: Re: timeformat annoys me...
Post by: Nao on April 5th, 2012, 01:05 PM
First sentence is okay but I'm afraid I didn't catch the rest.
How are you going to trim leading zeros on %d if it's in the middle of a string anyway...? Might as well use the trimmed version to begin with. SMF/Wedge already replace %e on the fly with %#d IIRC, if Windows is found.
Title: Re: timeformat annoys me...
Post by: Arantor on April 5th, 2012, 01:52 PM
Same way you were going to call trim() on it...?
Title: Re: timeformat annoys me...
Post by: Nao on April 5th, 2012, 02:57 PM
I'm calling trim() (or more specifically, ltrim because these never generate right padding AFAIK), on the final strftime() call, you know, just inside the return call...
Title: Re: timeformat annoys me...
Post by: Arantor on April 5th, 2012, 03:02 PM
I'm now thoroughly confused. You wanted to deal with the left spacing on the number, and suggested using trim(), I just suggested a variation on that which didn't use %e, nothing more.

For cases where there's an extra space in the middle of the string, you're still stuffed either way, whether you use ltrim() or trim(), aren't you?
Title: Re: timeformat annoys me...
Post by: Nao on April 5th, 2012, 03:37 PM
Quote from Arantor on April 5th, 2012, 03:02 PM
I'm now thoroughly confused. You wanted to deal with the left spacing on the number, and suggested using trim(), I just suggested a variation on that which didn't use %e, nothing more.
Okay, hmmm... Okay can I say that?

Let's say we have this:

Most users online: 127 (December  2)

In French, that would be:

Records de visiteurs : 127 ( 2 Décembre)

Notice the position of the extra space. Because HTML is pretty cool when it comes to multiple spaces, it will only show one space in "December 2", but will show the extra space in French.

My goal was initially to fix %e to return no padding. However, I don't really care that %e returns an extra space when HTML will deal with it. It's not a big deal... So, in the meantime I figured I should just call ltrim() on the final string (" 2 Décembre"). Do you understand what I mean...?
Quote
For cases where there's an extra space in the middle of the string, you're still stuffed either way, whether you use ltrim() or trim(), aren't you?
Yeah, but does it matter? Do you know of any language where the standard for dates is something like "Djèkêmbërr (2)"? In that case, yeah, that string would get the extra space... But I'm trying to work out of a 'realistic' goal, i.e. the most likely languages to be seen. English has an 80% chance to be used, Turkish has a pretty high chance too (in SMF at least -- in Wedge it's gonna start slow), and French will certainly be in the Top 5. So it needs some love.

And you're lucky, I haven't come around to adding the "1er" thingy. :P (Although we could somehow do it by, for instance, adding a custom %variable, which could be transformed at runtime to $txt['strftime_finish_n'] = 'th'; $txt['strftime_finish_1'] = 'st'; $txt['strftime_finish_2'] = 'nd'; $txt['strftime_finish_3'] = 'rd'; -- hmm... I'm a bit crazy :P Perhaps there's already such a thing built into PHP...
Title: Re: timeformat annoys me...
Post by: Arantor on April 5th, 2012, 03:41 PM
Quote
My goal was initially to fix %e to return no padding. However, I don't really care that %e returns an extra space when HTML will deal with it. It's not a big deal... So, in the meantime I figured I should just call ltrim() on the final string (" 2 Décembre"). Do you understand what I mean...?
I do, but somehow I had it in my brain that it was more complicated.

In any case, typically in America they write the date as Month Day, Year, so you get two spaces into the mix.

There is no magic st/nd/rd in PHP AFAIK.
Title: Re: timeformat annoys me...
Post by: Nao on April 5th, 2012, 03:59 PM
Two spaces? Not one?

About 1st etc, I guess this could be done... Really, adding a %wd (Wedge day) or something, which we strpos in timeformat(), and str_replace with ($day = ltrim(strftime('%d', $date))) . (isset($txt['date_day_finish_' . $date]) ? $txt['date_day_finish_' . $date] : $txt['date_day_finish_n'])... Would that do? Something like that (not tested :P)
Title: Re: timeformat annoys me...
Post by: Arantor on April 5th, 2012, 04:12 PM
Sure it would be two spaces, because if you have say March 5, you'd get March(normal space that would be there anyway)(space that would be left from %e)5.

Yes, what you're proposing should do the trick, though I'm not sure about speed necessarily :/
Title: Re: timeformat annoys me...
Post by: PantsManUK on April 5th, 2012, 04:13 PM
Quote from Arantor on April 5th, 2012, 03:41 PM
There is no magic st/nd/rd in PHP AFAIK.
Eh? God is dead... :sob:

PHP does do English ordinal suffixes for the day of the month.

Code: [Select]
<?php
// Prints something like: Monday 8th of August 2005 03:12:46 PM
date('l jS \of F Y h:i:s A');
?>

:edit: Ah, not in strftime() it doesn't. To quote from the comments however:-

Code: [Select]
dgudgeon at example dot com 14-Jul-2011 05:04
If moving from date() to strftime() to support additional languages, you may miss the ordinal suffix format option date('S'). Workaround this by adding an extra modifier (%O).

<?php
function my_strftime ($format$timestamp)
{
    
$format str_replace('%O'date('S'$timestamp), $format);    
    return 
strftime($format$timestamp);
}
?>
Title: Re: timeformat annoys me...
Post by: Nao on April 5th, 2012, 04:18 PM
Yeah but it's date(), so it would require doing some conversion work anyway... (from % variables to single-letter variables, at the very least.)
Title: Re: timeformat annoys me...
Post by: Arantor on April 5th, 2012, 05:06 PM
And that's the thing, date() doesn't take locale settings into account, meaning it will only support English, it won't support any other language - something that strftime does do... as you mentioned.

I see what you mean about the helper function but that's really not helpful in performance terms - timeformat is called at least once every page, and for many pages it's called 20+ times, and adding that helper function is going to make it slower.
Title: Re: timeformat annoys me...
Post by: PantsManUK on April 5th, 2012, 05:15 PM
I see. Rock and a hard place. :hmm:

You *could* do a single-pass function that regexes for dates in the output and inserts the locale-correct suffixes as necessary, but that's a heck of a lot of work for tiny bit of gain (the page will grammer correctly). Me, I say f*** it and leave the "naked number"; folks will learn to love it...
Title: Re: timeformat annoys me...
Post by: Nao on April 6th, 2012, 04:14 PM
So, I implemented the stuff and it works.

I named it %@ so that it doesn't clash with other names.
It should be noted, however, that I met a bug in Wedge's number_context() that I won't be able to fix without rethinking the whole thing.

Indeed, let's say I define custom lines for _n, _1, _2 and _3 in English (which is the case here obviously.) And custom lines for _n and _1 in French (it only needs 'premier/1er').
Now, what happens if you're in French mode and asking to convert an April 2 date?
Well I'll tell you. It won't find a custom _2 in the French language, but because it loads the English file as well, it does find it in English, and thus I find myself with a beautiful "2nd avril" as the date... Argh.

Any ideas, Pete? Having to add dummy entries for other languages (i.e. just reproduce what _n does in _2, _3, _21, _22, _23 and _31) is a sad waste of time and space... It does seems like the only 'logical' solution, but it certainly hurts extensibility a bit.
Title: Re: timeformat annoys me...
Post by: Arantor on April 6th, 2012, 04:28 PM
Is there not an actual linguistic equivalent in French for 2nd? I always thought there was.

And sadly there isn't a good way around this one - normally it's not a huge problem because most of the time we only have _1 and _n strings in English which will naturally be overridden in other languages. I don't think you can get around it, unless you drop it in English entirely and just leave it in other languages if they want to do so.
Title: Re: timeformat annoys me...
Post by: Nao on April 6th, 2012, 04:35 PM
Quote from Arantor on April 6th, 2012, 04:28 PM
Is there not an actual linguistic equivalent in French for 2nd? I always thought there was.
A small French lesson if you're interested :)
We have this list:
Premier, second (but we can also say "deuxième", they're both correct), troisième, quatrième, cinquième, sixième...
1er, 2nd (2ème), 3ème, 4ème, 5ème....
Basically, our "ème" is your "th", and we have "er" and "nd", BUT, this is only for enumerating things... When it comes to dates, we don't say "Avril le second", we say "Le deux avril", whether written or orally. So that is, "2 avril". But April 1st is "Le premier avril", so "1er avril". Seeing "1 avril" is grammatically incorrect in French (we can't say "Le un avril"), which is why I could never stand how French dates are implemented in computer systems in general... And everytime we roll back to the 1st of a month, I immediately cringe at the "1 (month name)" in the topic list...
Quote
And sadly there isn't a good way around this one - normally it's not a huge problem because most of the time we only have _1 and _n strings in English which will naturally be overridden in other languages. I don't think you can get around it, unless you drop it in English entirely and just leave it in other languages if they want to do so.
Hmm... But English has its rules, too. Grammatically, I'm pretty sure that "April the 1" is as bad as in French... :P
Title: Re: timeformat annoys me...
Post by: Arantor on April 6th, 2012, 04:45 PM
Yay, dates are just as much of a shit to cope with as timezones are!

Anyway, yes, English has rules, and they're all insane and largely ignored.

Consider this: April 1 - that's mostly how the Americans write it, and it's wrong, because it should really be April 1st, never mind the implied but missing 'the' in the middle that you mention.

But the English get it wrong too. We tend to write 1 April or 1st April, but that's linguistically wrong too - it's really '1st (of) April' with the implication of 'day' being in there.

Fortunately most people aren't anal enough to care about this and don't really notice it when it's 1 April or April 1 with or without the suffix, it's only those of us who *really* put in the attention to detail that would even notice, let alone do anything about it.

(For the record, it's something I'd like to see done right too, but I didn't know enough about how other languages did it to make a judgement call on how it should be done)
Title: Re: timeformat annoys me...
Post by: Nao on April 6th, 2012, 04:56 PM
Quote from Arantor on April 6th, 2012, 04:45 PM
Yay, dates are just as much of a shit to cope with as timezones are!
Oh, and I didn't even tell you yet...
When I when to change my time format, I noticed that my timezone was set to UTC/Dublin. No Paris in there. Looked into the list... No Paris either. Uh. After checking with Windows -- the Amsterdam (CET+1) timezone is different from the Brussels/Paris timezone (although also at CET+1). And it doesn't seem to be handled by Wedge at all...?
Isn't this a complete list of all timezones?
Also, is the fact that I was by default on UTC/Dublin due to me probably not going to that area before, and thus having no default timezone...? Because I saved my time format, and didn't notice the timezone at that moment, and I immediately got an incorrect forum time (well, YOUR correct forum time if you prefer :P). I had to go back to the page and noticed that it was Dublin by default.

I can already see the amount of support messages about this one...
Quote
Consider this: April 1 - that's mostly how the Americans write it, and it's wrong, because it should really be April 1st, never mind the implied but missing 'the' in the middle that you mention.
And it's good this way :P April 1st is what comes to mind naturally to me...
Quote
But the English get it wrong too. We tend to write 1 April or 1st April, but that's linguistically wrong too - it's really '1st (of) April' with the implication of 'day' being in there.
"1 April" sounds awfully wrong to me...
Quote
Fortunately most people aren't anal enough to care about this and don't really notice it when it's 1 April or April 1 with or without the suffix, it's only those of us who *really* put in the attention to detail that would even notice, let alone do anything about it.
So... Do you have any suggestions on the current affair at hand?
Quote
(For the record, it's something I'd like to see done right too, but I didn't know enough about how other languages did it to make a judgement call on how it should be done)
I think there's no 'right' way to do it -- they're all going to slow down the system.
But it can be optimized I suppose...
For instance, we could benchmark multiple strftime calls against something like explode(' ', strftime('%m %d %y %h %i %s')) (and the equivalent date()), with subsequent use of $txt['days'], $txt['months'] or things like that...
Thing is, I have no idea whether strftime is THAT slow. It seemed pretty pointless to try and optimize it further after I noticed that it took over 30.000 calls to timeformat() to get it to take a second to execute...!
Title: Re: timeformat annoys me...
Post by: Arantor on April 6th, 2012, 05:07 PM
Quote
Isn't this a complete list of all timezones?
Also, is the fact that I was by default on UTC/Dublin due to me probably not going to that area before, and thus having no default timezone...? Because I saved my time format, and didn't notice the timezone at that moment, and I immediately got an incorrect forum time (well, YOUR correct forum time if you prefer :P). I had to go back to the page and noticed that it was Dublin by default.
No, it's not a complete list of all timezones. There are nearly 500 (no that's not a typo) timezones to contend with. I've reduced it to a list of about 70 (75 IIRC) which are comparable to the ones Windows uses. Incidentally I think you'll find XenForo uses a similar if not the same list.

The timezone code has a bug where it can display the wrong entry in the list if the underlying timezone identifier has a _ in it. This is not a new bug and was discussed and investigated last week, I just haven't fixed it yet. But it still saves the correct timezone.

Check the timezone column in wedge_members to see what it's actually using for you - I'm on UTC Dublin, despite the server not being so.

Also, as far as I can determine, Amsterdam is not the same physical timezone but shares all the same rules with the Central European timezones, so that it is to all intents and purposes the same.


Regarding dates, I don't have a better solution, I'd prefer it to be as 'right' as possible, ultimately. April 1st would be better than April 1 which would be better than 1 April, but it's almost more a preference than anything else right now.

And yeah, optimising timeformat is one of those cases that it'd be neat but ultimately not a huge win in the scheme of things (IIRC, I already did some work to make it faster than SMF's by changing the setlocale call handling)
Title: Re: timeformat annoys me...
Post by: Nao on April 12th, 2012, 02:51 PM
Quote from Arantor on April 6th, 2012, 05:07 PM
No, it's not a complete list of all timezones. There are nearly 500 (no that's not a typo) timezones to contend with. I've reduced it to a list of about 70 (75 IIRC) which are comparable to the ones Windows uses. Incidentally I think you'll find XenForo uses a similar if not the same list.
Hmm it's complicated...
Quote
Check the timezone column in wedge_members to see what it's actually using for you - I'm on UTC Dublin, despite the server not being so.
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.
Quote
Also, as far as I can determine, Amsterdam is not the same physical timezone but shares all the same rules with the Central European timezones, so that it is to all intents and purposes the same.
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:
Quote
Regarding dates, I don't have a better solution, I'd prefer it to be as 'right' as possible, ultimately. April 1st would be better than April 1 which would be better than 1 April, but it's almost more a preference than anything else right now.
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?
Quote
And yeah, optimising timeformat is one of those cases that it'd be neat but ultimately not a huge win in the scheme of things (IIRC, I already did some work to make it faster than SMF's by changing the setlocale call handling)
Yeah, I remember that, it was a good idea :)
Title: Re: timeformat annoys me...
Post by: PantsManUK on April 12th, 2012, 03:03 PM
Getting back to the most immediate topic at hand (suffixes for dates), ignore the English suffixes when a non-English language is in use. Over-write the strings if that would help...
Title: Re: timeformat annoys me...
Post by: Nao on April 12th, 2012, 03:11 PM
Quote from PantsManUK on April 12th, 2012, 03:03 PM
Getting back to the most immediate topic at hand (suffixes for dates), ignore the English suffixes when a non-English language is in use. Over-write the strings if that would help...
No, can't do something specific like that... It would need to be built into the language loader (i.e. load English, and if another language is loaded, unset all English suffixes first), and I don't really like the idea.
Title: Re: timeformat annoys me...
Post by: Arantor on April 12th, 2012, 03:15 PM
Quote
since no timezones exist that require a 15mn granularity,
Yes there are, actually. India, for one.

But it's still kind of moot. There absolutely MUST be a timezone set. You can't even call time(), without having a timezone being set because PHP will complain bitterly. Same with strftime, date etc. And given that we already have to do that, it's no biggie to get the user's timezone that they've set, which allows us to calculate the offset relative to server time, including DST, and get it right. IIRC I implemented it so it calculated the time_format and overrode what the user had otherwise set to preserve codepaths.
Quote
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.
The time format should now be obsolete, and only timezone should be set. There's no clean way to determine a user's timezone by anything supplied by the user, far better that instead ask the user what their timezone is on registration. (This is not yet implemented but I'll add that in due course)
Quote
No, can't do something specific like that... It would need to be built into the language loader (i.e. load English, and if another language is loaded, unset all English suffixes), and I don't really like the idea.
It does have to be in the language loader, but you have choices in how it's done.

What you can do, if you want, is implement it as an array, such as:
Code: [Select]
$txt['day_suffix'] = array(
  1 => 'st',
  2 => 'nd',
  3 => 'rd',
  'n' => 'th',
);

Or, as previously discussed creating a set of prefixes. But this seems cleaner to me - and you can have it expanded automatically into a normal set of day_suffix_1, day_suffix_2 etc in loadLanguage, when the loaded language file is 'index', and have it automatically unset all of them and build them out of just this array.
Title: Re: timeformat annoys me...
Post by: Nao on April 12th, 2012, 03:48 PM
- 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()?
Title: Re: timeformat annoys me...
Post by: Arantor on April 12th, 2012, 03:57 PM
Hmm, I thought India was +5:45, but it seems to be +5:30.

And yes, I did get it confused with time_offset. (Am not at home today but have laptop with me)

Thing is, if we're being correct about suffixes, I'd prefer to be correct across the board ;)

As far as using that array goes, do it in loadLanguage, if the loaded language file is 'index'. It's called only a few times per page, far fewer than timeformat or number_context is.
Title: Re: timeformat annoys me...
Post by: Nao on April 12th, 2012, 04:04 PM
Alrighty...
Title: Re: timeformat annoys me...
Post by: Nao on April 12th, 2012, 05:23 PM
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.
Posted: April 12th, 2012, 05:11 PM

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...)
Title: Re: timeformat annoys me...
Post by: Arantor on April 12th, 2012, 06:31 PM
But surely you can't do it only once? If you load French, you load French after you load English... so you need to rebuild it when French is loaded - surely you need to do it just when $template_name === 'index' so that you always rebuild it properly when changing languages?

(That does raise questions for switching languages e.g. for emails but IIRC index isn't used then anyway)
Title: Re: timeformat annoys me...
Post by: Nao on April 12th, 2012, 07:02 PM
Quote from Arantor on April 12th, 2012, 06:31 PM
But surely you can't do it only once?
Don't call me Shirley!™
Quote
If you load French, you load French after you load English... so you need to rebuild it when French is loaded - surely you need to do it just when $template_name === 'index' so that you always rebuild it properly when changing languages?
I don't see the point in doing it twice with fallback. You only need to do it for the target language... Hence the $fallback bool I added. setlocale and day_suffix are now both skipped when the loop is in fallback mode.
Title: Re: timeformat annoys me...
Post by: Arantor on April 12th, 2012, 07:47 PM
Oh, I see, that makes sense :)
Title: Re: timeformat annoys me...
Post by: Nao on April 12th, 2012, 08:34 PM
I'll be committing that, then ;)