WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#3767 closed defect (bug) (wontfix)

Default theme (Kubrick) should use the blog's default date format, not "F jS, Y"

Reported by: johnbillion Owned by: ryan
Milestone: Priority: low
Severity: trivial Version: 2.2
Component: Template Keywords: has-patch
Focuses: Cc:

Description

In Options -> General it is possible to set the "default date format" and "default time format" to be displayed on your blog. However, Kubrick ignores these values and instead uses the_time('F jS, Y') for the post date. This means a user might change their date or time format and wonder why it is having no affect on their blog.

I propose a minor change to the Kubrick theme bundled with WP, so the_date() and the_time() are used without parameters, thus using the default date and time formats set in Options.

The following files in the default theme are affected:

  • archive.php (line 37)
  • attachment.php (line 29)
  • comments.php (line 36)
  • index.php (line 11)
  • search.php (line 19)
  • single.php (line 27)

The Classic theme isn't affected as it uses the_time() without parameters.

I apologise for not submitting diff files but I have no experience of them or CVS. I need to look into that.

Attachments (3)

changes.diff (3.8 KB) - added by johnbillion 7 years ago.
Changes to the six affected files in Kubrick
unsetpreviousday.diff (5.7 KB) - added by sunburntkamel 7 years ago.
patch including unset previous day
3767.diff (2.1 KB) - added by Nazgul 7 years ago.

Download all attachments as: .zip

Change History (28)

comment:1 in reply to: ↑ description foolswisdom7 years ago

Replying to johnbillion:

I apologise for not submitting diff files but I have no experience of them or CVS.
I need to look into that.

Contact me any time, you will be surprised how easy it is.

johnbillion7 years ago

Changes to the six affected files in Kubrick

comment:2 johnbillion7 years ago

Hurrah for learning Subversion in an hour!

comment:3 follow-up: ryan7 years ago

The default date format is fairly useless because it is devoid of context. Most themes use a number of different formats depending on the context. The formats are usually marked with gettext so that they can be altered by translators to suit the locale.

Kubrick uses two different formats. If we think it is acceptable to distill these down to one, the patch is fine by me. In general, however, themes usually ignore default date format because they want to control the time and date formats as elements of the theme's style.

comment:4 johnbillion7 years ago

Ryan, you're absolutely right about context, however the two formats used in Kubrick hardly differ at all and the theme would not suffer if they were distilled into one.

The two formats are

  • F jS, Y which produces something like February 11th 2007
  • l, F jS, Y which produces something like Sunday, 11th February, 2007

the only difference being the displaying of the day of the week.

Third party themes should still be free to choose the format which the date is displayed in (which they of course are) when it is appropriate, for example in a situation where the default date might not be concise enough. I think this is beyond the discussion of this ticket though because it is to do with raising awareness of using the default date format where possible in third party themes.

The point which I am trying to address is that surely WordPress noobs (and indeed seasoned users) would expect the date format to change on his/her default template according to the changes they make to the default date format under Options.

comment:5 MichaelH7 years ago

This begets the question, "Why have the Default date and time formats in Options->General if they are not useful for themes (see http://trac.wordpress.org/ticket/3767#comment:3) or for the admin UI (see http://trac.wordpress.org/ticket/2601#comment:2)?"

comment:6 johnbillion7 years ago

Absolutely right MichaelH. The option could be removed entirely if no-one or nothing is going to use the default. The only issue this raises is what format to display when none is specified in the template/admin area function, which brings us back to square one where a default date format is needed. Catch 22.

comment:7 Nazgul7 years ago

  • Keywords has-patch added; time date formatting theme kubrick removed

comment:8 foolswisdom7 years ago

  • Owner changed from anonymous to ryan

comment:9 foolswisdom7 years ago

  • Version set to 2.2

comment:10 rob1n7 years ago

Where do we use the date settings, anywhere in the code? I don't think it's particularly useful, and we might as well just drop the default date format option.

comment:11 abelcheung7 years ago

Probably it is sane to remove this option from option page. However, OTOH it is vital to make some of the frequently used date/time format localisable, so people won't end up seeing strange date formats not belonging to their languages.

comment:12 abelcheung7 years ago

  • Cc abelcheung added

comment:13 foolswisdom7 years ago

  • Milestone changed from 2.2 to 2.3

comment:14 sunburntkamel7 years ago

the reason most themes don't use the default formatting, is that when multiple posts are posted on the same day, the date only shows on the first one. so for index/archive pages, there needs to be

unset($previousday);

before

the_date()

is called without parameters.

sunburntkamel7 years ago

patch including unset previous day

Nazgul7 years ago

comment:15 follow-ups: Nazgul7 years ago

Added a patch which drops the default time and date format option from the General Options screen, because (as ryan mentions) they're useless without context.

I've left the backend in though, for backwards compatibility, for themes (and core code) which still use the option.

comment:16 rob1n7 years ago

They're used in the backend, IIRC.

comment:17 in reply to: ↑ 15 phr3ak7 years ago

sorry but i don't understand why don't remove the fix format of date in the default theme instead remove this feature?

comment:18 in reply to: ↑ 3 foolswisdom7 years ago

Replying to ryan:

The default date format is fairly useless because it is devoid of context. Most themes use a number of different formats depending on the context. The formats are usually marked with gettext so that they can be altered by translators to suit the locale.

Kubrick uses two different formats. If we think it is acceptable to distill these down to one, the patch is fine by me. In general, however, themes usually ignore default date format because they want to control the time and date formats as elements of the theme's style.

comment:19 rob1n7 years ago

  • Milestone 2.3 (trunk) deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Yes, I believe this has been discussed many times over. Wontfix.

comment:20 in reply to: ↑ 15 ; follow-up: foolswisdom7 years ago

Based on the discussion does it not make sense to remove this option from the UI with Nazgul's patch?

comment:21 in reply to: ↑ 20 ; follow-up: rob1n7 years ago

Replying to foolswisdom:

Based on the discussion does it not make sense to remove this option from the UI with Nazgul's patch?

I don't think so -- it's still used in the backend, I think. But neither are we going to change Kubrick's the_date() calls, so I guess, ...

comment:22 in reply to: ↑ 21 Nazgul7 years ago

Replying to rob1n:

I don't think so -- it's still used in the backend, I think. But neither are we going to change Kubrick's the_date() calls, so I guess, ...

It's indeed being used. But do you need to be able to change it from the admin?

comment:23 follow-up: rob1n7 years ago

I suppose so. I know for an example, British people use DD/MM/YY format, whereas Americans use MM/DD/YY. Or people want something like 1-31-93 2:32:12 am instead of January 31, 1993 @ 2:32 AM.

comment:24 in reply to: ↑ 23 Nazgul7 years ago

Replying to rob1n:

I suppose so. I know for an example, British people use DD/MM/YY format, whereas Americans use MM/DD/YY. Or people want something like 1-31-93 2:32:12 am instead of January 31, 1993 @ 2:32 AM.

Ok, but that kinda contradicts with the reason why #2601 was closed. We should either use it everywhere or nowhere and not something in between.

comment:25 rob1n7 years ago

Well, the problem IMO is that there's not context with the field in the admin. What if you want a different form of date, for aesthetic reasons? Or just want "Tuesday, January 21"?

Maybe we just put a note in that it's just for some places in the admin? That way we would avoid confusion when they don't see any effects taking place.

Note: See TracTickets for help on using tickets.