WordPress.org

Make WordPress Core

Opened 13 years ago

Closed 12 years ago

#6913 closed enhancement (wontfix)

Make the editor's time format (24-hour vs. 12-hour clock) configurable per user

Reported by: regulatethis Owned by:
Milestone: Priority: low
Severity: normal Version:
Component: Date/Time Keywords: has-patch
Focuses: Cc:

Description

A recent thread on the wp dev mailing list brought up the fact that some people have a hard time understanding 24-hour time and so are confused by the editor's usage of a 24-hour clock when modifying a post's or page's timestamp.

One potential solution for this issue is to make a profile options which lets a user change the way the editor displays its timestamp.

If this option is set to 24-hour, then the editor behaves as it does now, displaying the timestamp in 24 hour time e.g. 17:43. This option is the default in all cases.

If this option is set to 12-hour, then the editor displays the timestamp in 12 hour time e.g. 5:43pm. The user can then change the time and the meridiem (am/pm) using a dropdown box.

All internal representations of a post or page timestamp remain unchanged. Only the display of the timestamp is changed if the user chooses 12-hour time. In this case, code in post.php converts the time back to a 24-hour representation before committing the change to the db.

Attachments (2)

time_format_6913.diff (7.1 KB) - added by regulatethis 13 years ago.
Update of patch, fixing so 24 hour clock displays as default for an existing user without the option set (Thanks Alexander Beutl for pointing this out)
time_format_6913_rev2.diff (10.3 KB) - added by regulatethis 13 years ago.

Download all attachments as: .zip

Change History (12)

#1 @regulatethis
13 years ago

This is my first attempt at non-trivial WP hacking. This is a convenience feature (I understand 24-hour time perfectly ;) ) but might be a nice option.

Please comment if I've done anything stupid or with any improvements. I've run quite a few tests on this code and it seems to be working fine but then again I don't have that much experience with WP, so please test this!

#2 @ozh
13 years ago

Instead of a per-user setting, I'd rather see a global setting that can be per-user overridden.

@regulatethis
13 years ago

Update of patch, fixing so 24 hour clock displays as default for an existing user without the option set (Thanks Alexander Beutl for pointing this out)

#3 @regulatethis
13 years ago

Rev 2 of my patch:

  • Editor time format is now a global setting under Settings > General
  • User profiles can either 'default' to the global setting or override with 12 or 24 hour
  • Global settings defaults to 24-hour, and user profiles default to using global


Fixed:

  • Bug when entering "12" for the hour
  • Conflicting usage of "time_format" as an option name in wp_usermeta nad wp_options

#4 @regulatethis
13 years ago

  • Keywords has-patch added
  • Milestone changed from 2.7 to 2.6

#5 @ryan
13 years ago

12/24 preference can be derived from the "Time Format" setting. 'g' or 'h' in the format specifier indicates a 12 hour prefence. 'G' or 'H' indicates a 24 hour preference. Ideally, however, the post editor would use an inline date/time picker built on jQuery.

#6 @regulatethis
13 years ago

That's the time format for times displayed in most areas of the blog, but this doesn't affect the time format used for scheduling or editing a post's timestamp, which was always in 24-hour format.

My patch addresses the latter case.

Or am I missing something? :)

#7 @ryan
13 years ago

I'm just saying we don't need another time setting. We have too many time settings as is. This will probably all be moot once we add jQuery date/time picker that will be more friendly. If we want to offer a 12/24 option with the new picker, we can put a checkbox inline with the picker that saves the preference in a cookie or in usermeta and updates the time display on the fly.

#8 @regulatethis
13 years ago

Fair enough.

That said, it's a global setting that defaults to the current behavior and can be overriden if a user so desires (so I can't really see this cluttering/confusing anything).

As far as it being moot - if the jQuery date/time picker is already in the works then yeah I agree there's no point in making this change now. Otherwise, this could be a simple and quick enhancement until the jQuery stuff is put together and tested.

#9 @regulatethis
13 years ago

It's been a while and there doesn't seem to be any movement on this, either in trunk or in crazyhorse. Would this be up for reconsideration?

#10 @Denis-de-Bernardy
12 years ago

  • Component changed from General to Date/Time
  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

see #7665

Note: See TracTickets for help on using tickets.