Please restore date format editing ability in IPS4

[Tinytimrob]

I filed a bug about this before, but it was closed, since it is working as intended, so I figured I could try to make my case in a topic instead (because I think the intended behaviour is silly)

On my board I have both British and American members. The balance is probably around 50/50. Currently in IPS4 the date format is fixed to be "%x" and the locale can then be adjusted in the language pack. Because "%x" date format prints DD/MM/YYYY or MM/DD/YYYY depending on locale, if I want to please both the British and American members, I have to have 2 language packs installed (because the British will hate MM/DD/YYYY and Americans will hate DD/MM/YYYY)

I would rather not have two almost identical language packs installed just to set the date format, as that seems counter intuitive. I also would like to point out that if I created "English UK" language pack to fix the date formats, but then there were incorrect spellings (e.g. 'color'), then in order to make my website not be 'lying' to users by claiming to be UK language when it isn't, I would have to go and check every language string on the entire pack to make sure it was correctly localized. This seems like a huge amount of effort to me. (I suppose I could make "English US with UK dates" as a language, but to users that would seem like a really silly option)

Really I just want one single "English" language pack that works for everyone. If the spellings are slightly off it's no big deal, everyone knows what it means. But if the date formats are backwards, it's ambiguous, people might not be sure what 04/05/2015 is, for example. And again, some regular users will get annoyed. So my preferred date format would be "%d %b %Y" (prints as DD MMM YYYY, e.g. 15 Jan 2015) because this isn't ambiguous, it solves the confusion and then only 1 language pack is needed. Everyone would be able to identify the date without needing 2 packs installed or having to teach people how to switch between them. Maybe it wouldn't be the preferable option for some people to see DD MM YYYY format, but at least it would not be ambiguous like a date such as "04/05/2015" is.

I could previously edit the short date format to accommodate this change (very easy, just 1 setting to change in Admin CP), but unfortunately this setting was removed from IPS4.

As a temporary workaround, on my test board, I edited DateTime.php and replaced %x with %d %b %Y, so now all the dates are how I want them. It looks great, with immediate and non-ambiguous understanding of dates by members of all English speaking countries, and no complaints! But that's not really the best thing to do.

I am not sure why I have to edit the code to make this adjustment, when previously it was editable in the Admin CP. As it is, now every time there is IPS4 update, I have to check to see if DateTime.php is edited, and if it is, I have to repatch it. What a huge annoyance!

It is really sad that these sort of features are removed from IPS4 which are important to some communities such as mine, especially one like this which allows me to make the board more "international friendly" (something which is important to me as I have a lot of users from across the pond)

Maybe this isn't an important feature for most people, but I fail to see the issue with implementing an editable setting. Set it to "%x" by default, and hell, even hide it away in constants.php if you like, so the setting isn't visible to most users. But please, don't leave out this setting! It would really be a tiny amount of work to add it. And as long as the default was %x, it would continue to be changing with locale by default, which hopefully would satisfy most users.

Thanks for your time

[craigf136]

That makes logical sense, actually a family from the UK was refused visa's for a yearly holiday (they had one every year to the US). No criminal records or reasons to be refused, the airport that they flew into used a UK software company who had the date set as 11/08/ (11th August) but when it was all converted. The date was changed to 08/11 (8th November.)

To US authorities, the family had over stayed by 2 months - what's the moral of the story? Dates need to be in the correct format or all sorts of problems can occur.

[Myr]

I support this as well.  We have a very large non-us audience.

[Andy Millne]

On my board I have both British and American members. The balance is probably around 50/50. Currently in IPS4 the date format is fixed to be "%x" and the locale can then be adjusted in the language pack. Because "%x" date format prints DD/MM/YYYY or MM/DD/YYYY depending on locale, if I want to please both the British and American members, I have to have 2 language packs installed (because the British will hate MM/DD/YYYY and Americans will hate DD/MM/YYYY)

The dates should be adjusted to show in the correct format for the user that is viewing the date for exactly the reason craigf136 illustrated. Which is what we do by honouring the user's language choice. The locale is not just used for localizing dates, it is also used for currency, spelling, numeric formatting (decimal characters, thousands separators), string comparisons etc. There is lots to consider besides dates and for this reason it makes perfect sense to have separate language packs for these cases imo. 

[craigf136]

@Andy Millne - at the moment though, I only have the US language pack installed - which is fine, as I don't want to create UK specific one when the US one does just fine (apart from the obvious incorrect US spelling of things ;))

So the date will automatically change dependant on locale, so if US langauge pack (default) is installed, a UK person will get GMT and a US resident will get US time & date?

[Tinytimrob]

The dates should be adjusted to show in the correct format for the user that is viewing the date for exactly the reason craigf136 illustrated. Which is what we do by honouring the user's language choice

​But there are no language choices to pick from, other than English USA, without installing an English UK language pack. I don't want to do this for various reasons. Still, if other countries have minor differences like this, then in the end, I have to have slight variants of the English language pack for every single country, and maintain them all !!!

The locale is not just used for localizing dates

​I get this, but

it is also used for currency

​US and UK format currency identically. The only difference is the actual currency type itself, which, when you are selling things, is configurable in the Commerce app (I set it to GBP and everyone sees prices in GBP) and thus not affected by locale setting, at least nowhere relevant or in regular display across the site.

spelling

​Incorrect spelling is not ambiguous, but incorrect date format is.

If I put "aluminum" or "aluminium" in my discussion thread, you instantly understand what I mean, regardless of what variant of English you speak. The spelling is a non-issue here, since we are having international discussions in the forums anyway, and people spell differently; this is something you expect on a forum, especially one that tries to be locale-neutral.

On the other hand, with incorrect date formatting - if I put "04/05/2015" - what is the date? Is it 4th May? 5th April? WHO KNOWS! You have absolutely no idea!

This is why I want to change to "04 May 2015", because this is locale-neutral, or at least a lot more locale-neutral than 04/05/2015 vs 05/04/2015. Everyone understands the date immediately regardless of locale if the format is DD MMM YYYY.

numeric formatting (decimal characters, thousands separators), string comparisons etc.

Which, again, are exactly the same for US and UK as far as I know.

it makes perfect sense to have separate language packs

​No it doesn't. If I have separate language packs, I have to maintain them all. This is a lot of extra administrative work.

@Andy Millne - at the moment though, I only have the US language pack installed - which is fine, as I don't want to create UK specific one when the US one does just fine (apart from the obvious incorrect US spelling of things ;))

​^ This

So the date will automatically change dependant on locale, so if US langauge pack (default) is installed, a UK person will get GMT and a US resident will get US time & date?

​No - if a UK language pack isn't installed, everyone sees the US format regardless of where they are (at least from my observation).

As an experiment I tried changing the locale of the English language set (because only one is really needed) to "English UK" to see how long it would take before the grumbling began. Lo and behold...

Having two English language packs isn't an option really for us.

I wouldn't mind editing DateTime.php, but we used to have this option before... I'm complaining because we need it and you removed it

I'm currently paying for this software because it's the best. Version 4 is supposed to be an improvement over version 3, but at the moment I'm concerned because a lot of useful customization options have not been re-implemented, which is making it look like a much less functional suite. This is not the only removed feature that is annoyingly removed, but this issue causes the biggest annoyance for my site and its users.

The whole problem can be fixed by just adding one config setting - short date format - back in, and setting it to %x by default, meaning no default behaviour change at all as a result. And if you want, you can even make this a "customizable per locale" setting, to maintain your "locale friendly" design.

[TSP]

I have to say I initially agree that I would like this to be configurable globally again. While doing it automatically based on the by language pack locale seems a noble and decent idea at first, I still feel there are valid concerns. 

If the language locale (even what should be the correct one) doesn't format it like you want (it's incorrect for the language), then you'll need to contact your host to get it sorted? How obvious is this for admins? For example, the locale pack for norwegian on our servers are apparently "flawed" since it for some reason adds "+0000" after each date / time. What about those on a shared server environment, the locale may be "correct" for them and wrong for me, so they wouldn't necessarily be able to change it in that case. 

I'm also not too fond of the relative dates, neither seems my users. I feel it makes it confusing to figure out the time and insecurity on when something was really posted and in some cases you may want to see the exact time on something and not something ambigious like "2 hours ago" that is really anything in between 90 minutes and 150 minutes from now, I guess.

That said, I haven't looked really into how easy it is to edit these locale packs on the server to what you actually want to have (and how safe it is to assume that changes wouldn't suddenly be overwritten by the hosts. So this could be better than I think, but I'm just not convinced. 

[Andy Millne]

 in some cases you may want to see the exact time on something and not something ambigious like "2 hours ago" that is really anything in between 90 minutes and 150 minutes from now, I guess.

You can hover over the date to see the exact date adjusted for your locale if you wish. 

[Mark]

Very few places actually use the locale-aware date with almost all (at least on the front-end) dates displaying relative to the current time (e.g. "1 hour ago"). The relatively-displaying dates are super-smart and will even collapse to more condensed format (e.g. "1hr") on mobile devices. Due to this, the settings that 3.x used to have simply cannot exist any more.

For those rare places that do display the full date (and other things Andy mentioned), it is necessary to use the locale and not blanket apply rules (I know if you're only familiar with how things are done in the US and UK, this seems strange, but of course, users come from around the globe). With this in mind, I would like to, in a future version, divorce the locale awareness from the language packs. This will achieve exactly what you're looking for - you can have an "English" language pack, and no matter where the user is, we'll detect where they're coming from and display things appropriate to them whether they're in the UK, the US, France, Japan or anywhere. This won't happen for 4.0, but it is in my mind, and is a much more appropriate solution than throwing a setting in which would undo a lot of our internationalisation efforts.

In the meantime, a very simple plugin can maintain that code change for you. Here you go: Customisable Date Formats.xml (after installing, click the "Edit" button for the plugin) - Please be aware this plugin is not compatible with 4.2.0 or newer

Customisable Date Formats.xml

[Tinytimrob]

a very simple plugin can maintain that code change for you. Here you go

​Thank you very kindly for the plugin Mark! It is good as a workaround, and definitely better than having to edit DateTime.php on every IPS4 update, which would be a huge pain. I wasn't expecting to just be handed a free plugin so I appreciate it!

I just tried it out and it works great

I didn't realize the plugin system in IPS4 was so flexible in allowing these kinds of modifications. I had a peek at the developer documentation and it seems quite easy to make these sorts of plugins so this inspires me to try writing some myself 

Sadly it still seems to me like a step backwards when we have to resort to making or scrounging plugins to re-implement IPB 3.x features that have been removed

For those rare places that do display the full date (and other things Andy mentioned), it is necessary to use the locale and not blanket apply rules (I know if you're only familiar with how things are done in the US and UK, this seems strange, but of course, users come from around the globe). With this in mind, I would like to, in a future version, divorce the locale awareness from the language packs. This will achieve exactly what you're looking for - you can have an "English" language pack, and no matter where the user is, we'll detect where they're coming from and display things appropriate to them whether they're in the UK, the US, France, Japan or anywhere. This won't happen for 4.0, but it is in my mind, and is a much more appropriate solution than throwing a setting in which would undo a lot of our internationalisation efforts.

I think separating locale from language is a great idea and definitely one that should be implemented in 4.1, as it would solve problems like the one I described here; we would only need one language pack for English and everyone would see their preferred date format, etc.

On the topic of separation in a future version (and this is outside of the context of my own site): While I really don't see anyone running a small-to-moderate size English community going to the effort of maintaining multiple slightly different English language packs, it technically could happen. In that case, I think it's important to have some sort of "best language, best locale" system, especially for visitors. For example, if a guest comes from Canada, and only US and UK language packs are installed, they might see the UK language pack by default (because the spelling matches better) but the Canadian locale settings, whereas if someone from the US arrives, they should see US language and locale. Maybe this could be configured in the language pack or in some settings screen where we can set the preferred language pack for each locale? It would be pretty cool to be able to say "the default language for all locales is English USA. override the default language for UK, Canada, Australia, etc and set it to English UK instead. override the default language for all spanish locales, set to Spanish instead", etc.

Back on the topic of customization of date formats: What about in this circumstance...

If the language locale (even what should be the correct one) doesn't format it like you want (it's incorrect for the language), then you'll need to contact your host to get it sorted? How obvious is this for admins? For example, the locale pack for norwegian on our servers are apparently "flawed" since it for some reason adds "+0000" after each date / time. What about those on a shared server environment, the locale may be "correct" for them and wrong for me, so they wouldn't necessarily be able to change it in that case. 

I understand that a 'global' date-time format configuration setting (like the one in IPB 3 that I was complaining about being removed) doesn't really make sense once you consider such wider internationalization support, as you would then be overriding specific region settings with ones that would potentially be worse, breaking one locale to fix another.

In the instance above, only the Norwegian locale might have 'errors' so the changes would only be needed for that specific locale. So rather than removing the customization option altogether, maybe you could make the date-time formats customizable on a "per-locale" basis (or for now at least, a "per-language-pack" basis)? It would be nice to be able to make corrections to the default formatting for a specific locale/language in the event they don't match preference. (e.g. if i had English and French language packs installed but the French locale is wrong on my system, I could set a custom date format JUST for France)

I suppose a plugin could be made for that system, because maybe it's outside of the scope of the IPS suite to have that much control over what is effectively a system configuration setting. That sort of plugin is also not needed for my case, since the global setting works fine for me. Just throwing some ideas around

[The Old Man]

Hi,

I found this topic via search because Ive just come across this issue with having a UK and separate US calendars. It's visible in the Upcoming Calendar Events Hook. I'm in the UK but both calendars entries show as US style. The format for Calendar is in the main Calendar management settings and not in the settings for individual calendars, which may be resolved in v4.

 

[TracyIsland]

Interesting read.  Our community has members from 42 countries.  We're still on 3.3.4, so I have implemented a board wide standard of 23 Feb 2015 for everything.  That way there is no doubt what date we are talking about.

[BB Themes]

Sadly IPS does not adhere to the international standard format, but rather they try going with the american one.

[Charles]

Sadly IPS does not adhere to the international standard format, but rather they try going with the american one.

​You may wish to read this topic as your statement doesn't go along with what's being discussed

[BB Themes]

​You may wish to read this topic as your statement doesn't go along with what's being discussed

​This I know, I guess I did a thread hijack. This subforum is product feedback, right? As you have mod tools, I allow you to split the topic or put it wherever you wish as long as you say that it has been split from here. 
It is however true that you are using the date and time quite oddly. Examples are the above and the odd part that you are not using the ISO standard when it comes to showing date / time per default etc. PM / AM has no place, generally, on the international market as most countries use 24:00 format. Meh, there are more stuff but I guess you've heard and ignored it by now. The above here did not make me cancel my subscription, but It left a bad elitist taste In my mouth as the product seems to be made for americans rather than made for international use, mostly thinking about the date and time format here, mostly I think the product is far better than the competition offers. (For countries that do not use PM and AM, as an example, we have no clue what is what and thereby calendar events really cant be used until it has been tweaked.)

[Andy Millne]

It is however true that you are using the date and time quite oddly. Examples are the above and the odd part that you are not using the ISO standard when it comes to showing date / time per default etc. PM / AM has no place, generally, on the international market as most countries use 24:00 format. 

​Please re-read the topic as the behaviour you are expecting is explained in detail here. Dates are formatted according to the locale you set up in the ACP. If you are seeing dates in an American format and not for your region then you most likely have the locale set up incorrectly. The use of AM and PM is also determined based on the chosen locale. Some have expressed the desire to split date formatting away from the language selection which we don't disagree with and as Mark mentioned we will be considering this for future releases.

[BB Themes]

Ah, it seems that me not being able to swap locale in the past was the issue. Now with recent patches I can and that "solved" it. Kudos for that one, really. 

[The Old Man]

You can hover over the date to see the exact date adjusted for your locale if you wish. 

Unless you are using a mobile device like an iPad! 

[riven3d]

I just checked as a US member all my forums show the date in the UK setting with no way to fix this, I have just installed the plugin that was attached earlier in the the thread and it still shows incorrectly.

 

hovering over it does show the correct format but it does not display correctly at all on 4.0.7

this is the setting below and how it shows in post and on the forum index, no matter what i change it displays the same way and yes I have hard refreshed to see if the changes are there and nothing

 

 

[ThomasS]

Is this plugin the way to go for switching to HH:MM instead of AM/PM?

I'm a bit scared, that this will create problems with future updates and I'm a bit confused, that this software is not even offering the ISO standard

[Michel_72]

Be aware, merely installing this plugin just took my 4.2 site down completely. (error 500)