Unifying locale time formats

[Malte]

Hi!

I recently contributed the zh_CN, zh_TW, zh_Hans and zh_Hant locale formats. These locale formats enable dates and times to be formatted correctly in a given locale. While doing this, I noticed different authors have very different ideas of how time should be displayed, in particular, some authors decided for seconds to be part of standard time output. I really question the validity of having seconds in standard dates.

For you to get an idea of what files I am talking about, here is an example of a formats.py file for the locale zh_CN. Time is shown in the format H:i, so 20:45. Note the absence of seconds: https://github.com/django/django/blob/master/django/conf/locale/zh_CN/formats.py

In some locales, like German and Spanish, just to name two random examples, seconds are included in the standard time output. IMHO, seconds are not required in most use cases. Time output with seconds or even milli-seconds is relatively rare.

3 random examples:

In default en locale (English), the time output is 8:45 pm. 

In Chinese, it's 20:45. But in de locale (German), it's 20:45:29. 

In en locale (Spanish), it's not even uniformly applied.

Code examples from the respective locale/formats.py files:

EN (English): 

TIME_FORMAT = 'P'

DATETIME_FORMAT = 'N j, Y, P'

SHORT_DATETIME_FORMAT = 'm/d/Y P'

Conclusion: All time formats without seconds.

DE (German):

TIME_FORMAT = 'H:i:s'

DATETIME_FORMAT = 'j. F Y H:i:s'

SHORT_DATETIME_FORMAT = 'd.m.Y H:i:s'

Conclusion: All time formats with seconds.

ES (Spanish):

TIME_FORMAT = 'H:i:s'

DATETIME_FORMAT = r'j \d\e F \d\e Y \a \l\a\s H:i'

SHORT_DATETIME_FORMAT = 'd/m/Y H:i'

Conclusion: Not uniform. One time format with seconds, two time formats without seconds. 

I have two suggestions:

Option 1) Purge seconds from all time formats.

Option 2) Introduce new time formats.

What do you all think? I favor option 1. But I would like to hear what other devs think before opening a ticket. Perhaps I am the only one bothered by this. But when you are building a truly international project, locale formatting is crucial.

Cheers,

/malte

[Aymeric Augustin]

While there are some backwards compatibility concerns, I believe option 1 is better:

- It provides consistency out-of-the-box for international websites.

- It makes the default behavior more reasonable in general.

-- 

Aymeric.

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/61399a30-a442-44a6-9991-a1c5bfd3809c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Aymeric.

[Malte]

Hi Aymeric,

Yes, I agree. And backwards compatibility is a concern I share. But as it is right now, time output is not very useful if it includes seconds.

Few people will state:

"Posted on 10.9.2014 20:45:29".

[Wim Feijen]

Hi Malte, 

Sounds like a good idea to remove the seconds. Aymeric says the same.

Can you open a ticket and if you want create a pull request?

Wim

[Malte]

Hi Wim,

That's a lot of locales to change though. I am still somewhat new to Git. How would you go about it?

[duncan...@gmail.com]

On Wednesday, 10 September 2014 22:21:39 UTC+1, Malte wrote:

That's a lot of locales to change though. I am still somewhat new to Git. How would you go about it?

Oddly, I came to the same conclusion last night that seconds should be removed and was just contemplating writing a pull request for it. Can you give us a bit more idea of what you need to know about git? 'git commit -a' might help you here if you've changed a lot of files and you want to commit them all in one go (though make sure you have a nice fresh checkout before you start work as it's easy to add things by accident that way).

I'm happy to make the pull request if you prefer.

Cheers,

Duncan

[Andrew Pinkham]

On Sep 10, 2014, at 4:21 PM, Malte <malteb...@gmail.com> wrote:
> That's a lot of locales to change though. I am still somewhat new to Git. How would you go about it?

I asked about Git recently on the Django Core Mentorship list. Carl Meyer responded with a really good workflow for creating a PR. I have copied key parts of his response below.

Begin forwarded message:
> The best way [...] is to always use a new branch for
> each pull request, instead of making your changes directly in master.
> This way it doesn't matter whether your PR is merged exactly as-is, or
> is squashed or otherwise modified (as happened in this case) -- either
> way master always tracks exactly what happened upstream, without
> interference from your original version of the changes.
>
> Sample sequence of git commands you might use to make a new local branch
> and make a PR from it (with interspersed commentary):
>
> # First make sure your new branch will based on the latest master
> $ git checkout master
> # If your local master tracks upstream, you can omit "upstream master":
> $ git pull upstream master
>
> # Create a branch: I often name it tXXXXX for the Trac ticket #
> $ git checkout -b t22951
>
> # Make your changes and commit them...
>
> # Then push your local branch to a branch of the same name
> # on your GitHub remote. The -u sets up a "tracking" relationship,
> # so in future you can just "git push" from this branch and it will
> # automatically know where to push to.
> $ git push -u origin t22951
>
> Now if you visit GitHub shortly after this push, it'll automatically
> prompt you to create a pull-request from your recently-pushed t22951 branch.

Tim Graham also pointed me to a part of the documentation that may be helpful:

https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist

Hope that helps,
Andrew

[Malte Beckmann]

Hi Andrew! Hi Duncan!

Cheers for the instruction. I will open a ticket and make the changes this week.

Best,
malte

> --
> You received this message because you are subscribed to a topic in the Google Groups "Django developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/RCcsR8sGmX4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CBD94E54-A792-4C73-8699-9431AE6EE073%40andrewsforge.com.

[Malte Beckmann]

Hi,

I followed the guidelines (https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/working-with-git/), opened a ticket (https://code.djangoproject.com/ticket/23466) made the changes and can't commit because of some git error.

Here are the commands I entered:

1) [Forked Django]

2) $ git clone g...@github.com:maltebeckmann/django.git django

3) $ cd django && git remote add upstream g...@github.com:django/django.git

4) $ git fetch upstream

5) $ git checkout -b ticket_23466 upstream/master

6) Removed seconds from all formats.py files.

7) $ git add .

8) $ git commit -am “Removed seconds from all locales.”

Throws error message: "fatal: Paths with -a does not make"

What happened here?

Cheers!

[Collin Anderson]

If you did "git add .", you should be fine without the -a flag, just use git commit -m “Removed seconds from all locales.”

[Malte]

Cheers, Collin! That worked

[Wim Feijen]

Hi everyone,

I wonder if we should unify the time format which is sometimes displayed as G:i and sometimes as H:i, where hours are displayed with or without a leading zero. For the same reasons as stated above I think it nicer to be consistent here. I would prefer G:i (hour without leading zero). 

Or is that a problem in some languages?

@Malte Your pull request looks good to me! Can you add a line to the release notes? Then I will mark it as Ready for checkin.

Wim

[Claude Paroz]

On Saturday, September 13, 2014 10:01:56 AM UTC+2, Wim Feijen wrote:

Hi everyone,

I wonder if we should unify the time format which is sometimes displayed as G:i and sometimes as H:i, where hours are displayed with or without a leading zero. For the same reasons as stated above I think it nicer to be consistent here. I would prefer G:i (hour without leading zero). 

Or is that a problem in some languages?

I think that this might be language/country specific, so I wouldn't unify it in a general manner.

Claude