It would be really useful to have a global region format setting.
An american is expecting something like:
Monday, November 12, 2012
11/12/12
03:45pm
In contrast, a german is expecting something like:
Monday, 12. November 2012
12.11.12
15:45
There should be some methods which expect an DateTime object as parameter.
For example if a user set region format to US:
OC_Localization::getTime($datetimeobject) - returns 03:45pm
OC_Localization::getShortDate($datetimeobject) - returns 11/12/12
OC_Localization::getFullDate($datetimeobject) - Monday, November 12, 2012
Furthermore, it should be possible to parse localized dates
OC_Localization::parseTime('03:45pm') - returns an DateTime object
OC_Localization::parseShortDate('returns 11/12/12') - returns an DateTime object
OC_Localization::parseFullDate('Monday, November 12, 2012') - returns an DateTime object
georgehrke
All 53 comments
@DeepDiver1975 would be useful for formatting dates in the mail app as well
georgehrke
on 12 Nov 2012
sure - makes sense through out ownCloud
I wonder if there is something reusable out there .....
DeepDiver1975
on 12 Nov 2012
OC_L10N::l() already takes care about the localized print out.
https://github.com/owncloud/core/blob/master/lib/l10n.php#L211
Maybe we need to revive it - as I currently don't get where the language specific format strings come from.
@jakobsack
DeepDiver1975
on 13 Nov 2012
Please read https://www.xkcd.com/1179/
cryptomilk
on 17 Mar 2013
I see your point and agree with you from a technical point of view, but people don't want 2013-02-27. People want dates that are formatted like the dates they use in their daily life.
georgehrke
on 17 Mar 2013
@jancborchardt What's your opinion?
georgehrke
on 17 Mar 2013
Our life would be much easier if everyone would use the same format, but if we don't support it it will never happen. I've learned to use ISO8601 in school, didn't you?
cryptomilk
on 17 Mar 2013
No, in which class did you learn to use ISO8601?
georgehrke
on 17 Mar 2013
Our life would be much easier
Certainly, but people don't want to change their behavior
georgehrke
on 17 Mar 2013
The US has supposedly gone over to using the metric system years ago, but they just don't know it yet, so I doubt changing the date format happens overnight. btw, notice the hover title text on https://www.xkcd.com/1179/ where he is - deliberately - not using the ISO standard :smile:
tanghus
on 17 Mar 2013
The US has supposedly gone over to using the metric system years ago, but they just don't know it yet
georgehrke
on 17 Mar 2013
but we get off the subject
georgehrke
on 17 Mar 2013
but we get off the subject
It's Sunday - wait, is that start or end of week? ;)
tanghus
on 17 Mar 2013
But just for the fun of it: Metric Conversion Act of 1975
tanghus
on 17 Mar 2013
I’d be in favor of, for the web interface, simplifying the format to:
- Monday, November 12, 2012
- 2012-11-12
- 13:45
- Monday is first day of the week
And getting rid of the chooser for 12h/24h as well as the Monday/Sunday first day of the week crap.
That’s my opinion only though. Now the question is if there are customers who explicitly requested that there be these choices. If so, we probably (unfortunately) have to have them in. Is that the case?
jancborchardt
on 17 Mar 2013
@jancborchardt Nope... Let us Americans choose our 12 hour format and first day on Sunday.
MTGap
on 18 Mar 2013
Damn … alright alright.
jancborchardt
on 18 Mar 2013
People in different countries have different behavior - and diversity is good!
There is no need in educating people regarding their habits.
A professional calendar software has to respect all these things.
But again: is there really the need to reinvent the wheel? I think there are solutions out there.
DeepDiver1975
on 20 Mar 2013
I think a good solution would be to break English up into "English (US)", "English (GB)", etc and make that drive how dates are formatted.
jprjr
on 30 May 2013
I'd say rather than hide them behind potentially cryptic cultural conventions (English US) I'd say just display the format from a list and let the user choose one of:
- 2013-03-04
- 03-04-2013
- 04-03-2013
- March 04 2013
- 04 March 2013
theoretick
on 30 May 2013
BTW, the displayed date separator should also be configurable, like:
- 04.03.2013
- 04/03/2013
j-ed
on 23 Jun 2013
And that’s why there will be a global region format instead of being able to configure every single one of these uninteresting aspects of date formatting. We will not let users choose one of a list, but try to make sure that it just works, according what they are used to.
It’s not a potentially cryptic cultural convention, but a simple way to let people choose their region format. Let’s see how a sane piece of software does this:
Simple country chooser, which decides on format for time, date and phone numbers. First day of the week and 12/24h should also be decided by that. Default is initially set same as the language, but can be changed manually (see screenshot for instance).
@georgehrke can you do this, centrally in core personal settings and move all this date and time formatting stuff out of the Calendar?
jancborchardt
on 23 Jun 2013
Default is initially set same as the language
What's about UK and US. Make US default ?
@georgehrke can you do this, centrally in core personal settings and move all this date and time formatting stuff out of the Calendar?
We should first work out a concept how to implement this.
georgehrke
on 23 Jun 2013
all this date and time formatting stuff
AFAIK date and time formatting is already handled be the l10n module we have in place.
We should first work out a concept how to implement this.
:+1: for concept first
DeepDiver1975
on 23 Jun 2013
Code reading formats based on language:
https://github.com/owncloud/core/blob/master/lib/l10n.php#L143
DeepDiver1975
on 23 Jun 2013
https://github.com/owncloud/core/blob/master/core/l10n/l10n-en.php
https://github.com/owncloud/core/blob/master/core/l10n/l10n-de.php
https://github.com/owncloud/core/blob/master/core/l10n/l10n-es.php
DeepDiver1975
on 23 Jun 2013
Code reading formats based on language:
https://github.com/owncloud/core/blob/master/lib/l10n.php#L143
Do we use this anywhere?
georgehrke
on 23 Jun 2013
https://github.com/owncloud/core/blob/master/core/l10n/l10n-en.php
https://github.com/owncloud/core/blob/master/core/l10n/l10n-de.php
https://github.com/owncloud/core/blob/master/core/l10n/l10n-es.php
Well, this is not a very good solution. (imho)
The best solution is probably transifex, but with transifex we would have to split english up to english UK and english US.
we could do something like:
$datetime->format($l10n->t('m/d/Y'));
If you wonder which should be the default it is pretty simple: https://www.xkcd.com/1179/
cryptomilk
on 23 Jun 2013
If you wonder which should be the default it is pretty simple: https://www.xkcd.com/1179/
You already posted this xkcd :P see github.com/owncloud/core/issues/376#issuecomment-15020729
I totally see your point, but we don't (at least I don't) want to force people to adopt a new date format. ownCloud should use the date format people use in their daily life.
georgehrke
on 23 Jun 2013
Well, then make it configurable but the default should be the ISO ...
cryptomilk
on 23 Jun 2013
Do we use this anywhere?
In addition to wide used l10n::t() there is l10n::l() https://github.com/owncloud/core/blob/master/lib/l10n.php#L225
DeepDiver1975
on 23 Jun 2013
$datetime->format($l10n->t('m/d/Y'));
$l10n->l(datetime) should do the trick
DeepDiver1975
on 23 Jun 2013
The best solution is probably transifex
No way - we had formats on the translations in the past and translators totally fucked it up.
In addition I see no reason as all format for all supported languages should be available somewhere.
DeepDiver1975
on 23 Jun 2013
Usage of l():
https://github.com/owncloud/core/blob/master/core/js/config.php#L31
https://github.com/owncloud/core/blob/master/core/js/config.php#L59
https://github.com/owncloud/core/blob/master/lib/util.php#L165
Last one is formatDate() - is this the function we use consequently everywhere?
DeepDiver1975
on 24 Jun 2013
@DeepDiver1975
In addition I see no reason as all format for all supported languages should be available somewhere.
Zend has pretty structured xml for that, so de.xml defines general rules while de_CH.xml overrides some specific options.
It might be an overkill but I like this idea :baby_chick:
http://framework.zend.com/manual/1.12/en/zend.locale.appendix.html
VicDeo
on 26 Jun 2013
What’s the progress on this?
jancborchardt
on 20 Jul 2013
From my point of view we have everything in place - just some languages are missing.
DeepDiver1975
on 20 Jul 2013
Any status change on this? Having dates formatted and start-of-week day contrary to what end-users are comfortable with is a serious barrier to end-user acceptance and adoption.
skavoovie
on 11 Feb 2014
any news?
snaut
on 13 Mar 2014
From my point of view we have everything in place - just some languages are missing.
@DeepDiver1975 Are you referring to zend_locale?
georgehrke
on 27 Jul 2014
closing in favor of https://github.com/owncloud/core/issues/10220
georgehrke
on 26 Aug 2014
@georgehrke this is not the same. #10220 is about library and functions. This is about moving the region settings out of the Calendar app into core (the personal settings), so other apps can use it as well even when the Calendar is not installed.
jancborchardt
on 27 Aug 2014
@georgehrke this is not the same. #10220 is about library and functions. This is about moving the region settings out of the Calendar app into core (the personal settings), so other apps can use it as well even when the Calendar is not installed.
As discussed in #10220 it's better to generate the localized date in js. That's what Moment.JS is used for.
See all the benefits described in https://github.com/owncloud/core/issues/10220#issuecomment-51653283. It doesn't make sense to reimplement this in the server-side if there is a working solution already.
Moment.js comes with all the different locals, so there is no need for us to take care about this.
If you think this dropdown is necessary we can also tell moment.js to use a certain locale. http://momentjs.com/docs/#/i18n/instance-locale/
georgehrke
on 27 Aug 2014
Ok, so we won’t have a date format setting at all, anywhere?
jancborchardt
on 27 Aug 2014
No, there is no need for it
georgehrke
on 27 Aug 2014
Ok, then after #10220 we should remove all that stuff from the Calendar then.
jancborchardt
on 27 Aug 2014
reopened because there should be a dedicated region setting
georgehrke
on 21 Mar 2016
Almost the oldest issue on GitHub, any new here? :)
enoch85
on 24 May 2016
Hello, a user here!
I always prefer English UI with Finnish or ISO date format. It should be possible to set combinations like this.
vsq
on 12 Jul 2016
@vsq as you can see from the screenshot I posted above https://github.com/owncloud/core/issues/376#issuecomment-19878427, of course language and date format will be separate.
jancborchardt
on 12 Jul 2016
@DeepDiver1975 @PVince81 Can you please assign a milestone
georgehrke
on 12 Jul 2016
before this can work, there is more work to be done especially regarding numbers in the web UI: https://github.com/owncloud/core/issues/20674
PVince81
on 12 Jul 2016
Related issues
j-holub
·
3Comments
tommis
·
5Comments
fridaynext
·
5Comments
HLeemans
·
4Comments
ho4ho
·
3Comments