Allow custom formatting of due date strings.

[cahrens]

STUD-724

Allow specification of a format for due dates in LMS. See http://docs.python.org/2/library/datetime.html#strftime-strptime-behavior for syntax of format string.

For context, the issue here is that last fall we started showing the timezone on due dates. This bothered some course authors because they were using grace periods to "mask" what the timezone is. In response to their feedbac, we added a setting to hide the timezone ("show_timezone"). However, come this semester, it turns out that what they REALLY want is to hide the time part of the date completely. I decided to solve this by allowing them to completely control the formatting of the due date (which is how I wish I had done it in the past....).

Set the due date format in Studio, Advanced Settings, under the key "due_date_display_format".

Includes unit tests for the 2 places in LMS code where the due date is displayed (left-hand accordion, progress page).

Also removed a usage of django.utils.translation in common, as common should not depend on django. Currently we have no i18n process for things in common.

[cahrens]

@markchang This is ready for testing.

Before you check out the branch, set show_timezone=False in a Studio course. That way you can test the migration path after you check out the branch (show_timezone will not be visible in Advanced Settings).

[cahrens]

@sarina Can you code review? This touches LMS files.

@singingwolfboy can I get a review from you as well?

[cahrens]

Added some context in the description.

[ichuang]

Could some documentation be added giving examples of legal due_date_display_format strings? Many folks are unfamiliar with strptime strings. Sample strings, eg which show up in Studio, would be very helpful to users.

[cahrens]

We don't have documentation in Studio for things under "Advanced Settings". The expectation is that how to use these properties will be communicated to course staff on a need-to-know basis. @markchang has purposefully chosen to have us NOT display the help strings for these items.

We really, really hope that very few people will feel the need to change how due dates are formatted....

If there is static documentation someplace for this sort of thing, I'm happy to update that.

[ichuang]

Ah - well, every on-campus course at MIT using the edX-platform will want to change the date string, based on feedback we're getting. Folks want (1) dates in EST / EDT, and (2) simplified dates, with less confusing detail. I would guess that any residential campus use of the platform will want similarly.

[cahrens]

Note that the dates are still really UTC dates-- we only store UTC dates on the server. If someone displays them as any other timezone, they have to modify the graceperiod accordingly to "fake it".

If this really is a feature that will be widely used, it should be promoted out of Advanced Settings into the actual course settings (it would make sense to put it along side the grace period). I'll put a story on the backlog for that and we can monitor feedback.

[cahrens]

We also would like at some point in the future to have display of dates depend on the client browser (so dates would be translated properly into the user's timezone). This would address #1 and would require passing the formatting string to the client.

I created https://edx-wiki.atlassian.net/browse/STUD-753.

[ichuang]

That's reasonable. Thanks, @cahrens

[singingwolfboy]

Perhaps we should add a comment here explaining why we can't internationalize the word "at"?

[cahrens]

All the strings in common aren't translated (and there's a lot of them). I don't think we want to put comments throughout the code.

(BTW, I already bullied DB in person about this-- just updating the PR to reflect that).

[singingwolfboy]

Looks good to me. 👍

[sarina]

] on final line, as per https://github.com/edx/edx-platform/wiki/Python-Guidelines ("Breaking long lines" section)

[cahrens]

I'm not sure it applies in this case. It is not showing up in the pep8/pylint violations.

[sarina]

It's not a violation, just a style we're aiming for.

[cahrens]

But that guideline is specifically about function calls. Unless I'm missing something....

[sarina]

Eh I always thought it was for all long things, no big deal then.

[sarina]

Asked around LMS team. It's a preferred style thing - we all do the indentation of long lines the same way for function calls as well as long structs like lists, tuples, dictionaries. but it's not a requirement, just a preference for consistent styling in our code base. so whatever I suppose you want to do as long as that's clear.

[sarina]

Local dev environment finally working! All seems good to me.

[cahrens]

OK, addressed pep8/pylint warnings and also changed the style of list. Thanks for the review, @sarina. So you are 👍 after the tests have run again?

[sarina]

Yep 👍 😎

On Thu, Sep 12, 2013 at 1:29 PM, Christina Roberts <notifications@github.com

wrote:

OK, addressed pep8/pylint warnings and also changed the style of list.
Thanks for the review, @sarina https://github.com/sarina. So you are [image:
👍] after the tests have run again?

—
Reply to this email directly or view it on GitHubhttps://github.com/edx/edx-platform/pull/916#issuecomment-24339854
.

[markchang]

@ichuang all good points. we are putting this in as a quick stop gap to give ultimate control for those that really want it (and it is not super easy, as you pointed out). Otherwise, it is fairly low priority (given other work) to surface a comfortable UI for tweaking this display element. I hope that clarifies where we are coming from.