Make WordPress Core

Opened 10 years ago

Closed 8 years ago

Last modified 8 years ago

#26977 closed defect (bug) (wontfix)

Changing TimeZone Does Not Take Into Account Existing Post Timestamps

Reported by: cais's profile cais Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.8
Component: Date/Time Keywords:
Focuses: Cc:

Description

I do not believe this has been addressed but I also see this as an issue (although very edge-case).

Currently testing various and sundry items I noticed the post time stamp was not correct (minor detail but what also pointed out this issue), for example with the default UTC+0 timezone in affect a post can be written at 2:04 PM "local" time; now seeing this I changed to my "local" time (Toronto) saved settings and published a new post. The new post has a time-stamp of 12:42 PM ... and it appears *after* the post time-stamped at 2:04 PM which IMO puts the post order out of correct time sequence.

Yes, the time-stamp of the posts are correctly ordered but the time is not actually correct as the first post was written at 9:04 AM based on the "new" (current) timezone.

Unknown if relevant but in this case the time is being collected via get_the_time (or get_the_modified_time as the case may be).

Change History (3)

#1 follow-up: @DrewAPicture
10 years ago

  • Keywords close added

This seems like the expected behavior here. The post time – rather the post date – is based on the current time adjusted for the current GMT offset at the time of saving.

So to expect a saved value to adjust based on a new GMT offset seems out of scope. If I'm misunderstanding the premise, please correct me :-)

Suggest invalid/wontfix.

#2 in reply to: ↑ 1 @cais
10 years ago

Replying to DrewAPicture:

This seems like the expected behavior here. The post time – rather the post date – is based on the current time adjusted for the current GMT offset at the time of saving.

I would say this is expected bahavior simply because that is exactly how it is working but I still would not say it is correct.

So to expect a saved value to adjust based on a new GMT offset seems out of scope. If I'm misunderstanding the premise, please correct me :-)

This is exactly the premise I am suggesting ... being out of scope would imply it is not possible to make these changes.

Suggest invalid/wontfix.

I could see a "wontfix" resolution on this because it is very much edge-cases involved but that still does not make the issue invalid ... just something that was chosen to be ignored.

#3 @chriscct7
8 years ago

  • Keywords close removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

No further interest in 2 years. If interest re-emerges, feel free to reopen.

Last edited 8 years ago by chriscct7 (previous) (diff)
Note: See TracTickets for help on using tickets.