Add user-level & front end timezone display flexibility according to a fixed time [GMT:0]

[RanYanivHartstein]

Timezone can currently only be set on the blog level. This makes sure that the blog displays times in the timezone chosen by the blog's owner.

It would also make sense to add a timezone setting for registered users, so we can show times in their own timezone, or use that setting as a default for new blogs or other features in a multi-site setting.

[ramiy]

+1

[westi]

I'm not sure what in core would use this information.

It sounds more like something that a specific multi-site install might add and make use of.

However, if we add per-user locale features to core then it would probably make sense to include timezone as well then.

[jane]

@westi: I would guess things like showing publish time, etc? However, I would call this a new feature, not just an enhancement.

[westi]

Replying to jane:

@westi: I would guess things like showing publish time, etc? However, I would call this a new feature, not just an enhancement.

Yes and agreed this is very much a feature request - 'User Locale' would probably be the feature.

[nacin]

Probably very safe to close this until it gains traction.

[elyobo]

I'm in favour. What do you mean by gaining traction? How can we increase said traction? ;)

[sdefranc]

Now that Wordpress is being touted as a full-fledged CMS, it's about time this feature was re-examined, as Wordpress should account for the myriad of possible post types that make use of a date and time field which should be displayed in a users own timezone (Events and Meetings are just a couple of types that come to mind). Having it standardised and located in the WP core would be a great plus.

[ramiy]

Replying to sdefranc:

Not post-type, user-meta.

[rianjs]

I was putting the finishing touches on a plugin this morning, and thinking about date formatting, and I googled for a good ten minutes before I realize that there is no user-specific time zone setting in WordPress.

I was flabbergasted: the notion of a "server time" exists, which is used as the default for showing the dates and times of posts. But no time zone for registered users? That's a big oversight.

Sure, have a non-UTC fallback "server time" for unregistered readers, but the ability for a user to specify what time zone they're in is pretty standard across just about every other PHP application I've developed for... MediaWiki, Drupal, and phpBB ALL have the notion of "time zone associated with a registered user".

We have about 4,000 registered users scattered across the world. Being able to do a simple things like display the post or comment metadata as it relates to them, is a natural and desirable thing to do. WordPress core already stores date and time metadata in UTC format, and then applies a filter to show dates and times as whatever the server admin set.

Why not add a usermeta field so core and third-party developers can do the sensible thing and show post and comment metadata as it relates to the reader? (Especially if they were engaged enough to register.)

[maiden_taiwan]

I agree with the previous commenter. If your blog has users all over the world, they should see times and timestamps relative to their own time zone, not relative to the physical location of the server.

[nacin]

I'm all for something to happen here, but this would be a ton of work.

[rianjs]

I'm not sure the whole elephant needs to be swallowed in one gulp. Perhaps/probably I am underestimating the complexity of the task.

I would break it down into stages...

Part 1: Building the infrastructure

• Create a user_timezone field in usermeta when a user registers (or updates their tz preferences) in wp-admin
• Add a tz dropdown to wp_admin/profile.php (generated with wp_timezone_choice?).
• I don't think the add/update/delete/get_user_meta functions would need to be touched, as they seem pretty generic(?).
• Get the translation work done for the new db and UI elements
• Update the docs to include information about the new field

It looks as though WP saves metadata in both local (server) time, and UTC (gmt) time. That should make it very easy to create a filter to convert a UTC timestamp to the user's local time in Phase 2.

Part 2: Making use of the capability in the core

• Show users post and comment metadata in their time zone, if they have specified one, otherwise using the server's default time zone
• Relevant translation work
• Update the docs for elements that are making use of the new field

Part n: Infinity and beyond

• Socializing the capability so plugin authors can make use of it in their plugins

I have some free time on nights and weekends, and I'm game to work on the non-translation parts of Phase 1 and the "show post and comment metadata in a user's local time" from Phase 2. (I've done a quite a bit of development work involving PHP time zone handling and conversions.)

I know I must be missing other pieces of the puzzle... what other pitfalls and unknowns await?

[swissspidy]

First partial patch

[swissspidy]

I was digging into the code to see how we should implement it the best way and I'm still trying out different things.

Would love to see this feature in WordPress. So for a first try I created a small patch (far from perfect) that does the following:

• Creates a user_timezone field, whitelists this field and saves it to the database
• Modifies the wp_timezone_choicefunction to exclude manual GMT offsets using a second argument.

Note on the manual offsets: It seems like WP uses them in the general options for backwards compatibility and they aren't necessary for user timezones.

For part 2 (and n) I think the easiest way would be to use PHP DateTime functions to respect the timezones. But I'm unsure on how to best do this so I'm open for ideas.

[SergeyBiryukov]

Replying to swissspidy:

Note on the manual offsets: It seems like WP uses them in the general options for backwards compatibility and they aren't necessary for user timezones.

I'd prefer to keep manual offsets for user timezones as well.

​Moscow Time was changed to year-round UTC+4 three years ago, however not all servers have the relevant timezone information. So the Russian package currently uses a manual offset (UTC+4) rather than a timezone string (Europe/Moscow) in ​translation files.

[swissspidy]

Interesting! I didn't know that. Then it makes sense to include these offsets as well. Then it would behave like in core using a user_timezone and a gmt_offsetvalue for manual offsets.

I'll update the patch accordingly. Maybe this makes it easier to implement the various filters. Will check that as well.

[rianjs]

Replying to SergeyBiryukov:

Replying to swissspidy:

Note on the manual offsets: It seems like WP uses them in the general options for backwards compatibility and they aren't necessary for user timezones.

I'd prefer to keep manual offsets for user timezones as well.

​Moscow Time was changed to year-round UTC+4 three years ago, however not all servers have the relevant timezone information. So the Russian package currently uses a manual offset (UTC+4) rather than a timezone string (Europe/Moscow) in ​translation files.

Handling this at the application level because a server admin hasn't updated tzdata in three years is building needless technical debt that will have to be retired later.

[SergeyBiryukov]

Replying to rianjs:

Handling this at the application level because a server admin hasn't updated tzdata in three years is building needless technical debt that will have to be retired later.

We already support manual offsets on site level, and it doesn't look like they are going to be removed anytime soon, so I guess we can just reuse what we have without creating too much overhead.

[alexkingorg]

To make this compatible with caching, perhaps it should be built as a feature where front-end dates are output in GMT and there is JS that overwrites them to the user's local time?

[swissspidy]

Also see #28636

[johnjamesjacoby]

I've considered this a huge oversight for years, particularly for the bb's where minutes and seconds often matter. That said, the internet has changed and WordPress not having these settings polluting usermeta works in our favor now that modern browsers and a bit of JavaScript can guess a user locale relatively accurately (proxies and VPN's yadda yadda yadda)

I'd like to propose we include in core an extremely lightweight script to sniff the client timezone and provide the option of adjusting output using a time tag in themes with proper micro-formatting and an optional data attribute to allow said JavaScript to update the tag accordingly.

To take this even further, we could attach timezone_string metadata to each post & comment object based on where the author was located when they posted it. This way we can calculate both the GMT offset and, quite politely, the user-to-user offset to propagate a where-in-the-world effect amongst all WordPress powered sites.

Should a user wish to stay timezone agnostic, we can fallback on server time & GMT the same as we do currently.

[Viper007Bond]

@swisspidy pointed me at this ticket. Many years back, I stole some JavaScript out of the ​P2 theme and rolled it into a stand-alone plugin that basically does exactly what @johnjamesjacoby describes:

​https://wordpress.org/plugins/localtime/

It's a fairly simple plugin but it's not 100% compatible as it injects HTML into the date and time functions. If you use the return values of these functions as say a title attribute (and properly escape it), then you end up seeing the HTML. Something to think about.

I wrote the plugin as "activate and done" but if similar functionality made it into core, you'd probably want new functions or something.

[writegnj]

Any update on this? this is the function that I have been waiting for years.

[solhuebner]

+1 for implementation as it supports the i18n efforts :-)

[swissspidy]

Proof-of-concept

[swissspidy]

After talking to @ocean90 at WordCamp Cologne about the recent user language efforts, I've been looking into this again.

I updated the previous patch that now does the following:

• Add a new timezone string to the user-edit.php screen. Options are saved to two usermeta fields ( gmt_offset and timezone_string, just like in core).
• As a proof-of-concept, a wp_timezone_override_user_offset function is used on the edit screen to filter the gmt_offset option to respect the user's setting.

Thoughts:

• There's lots of similar code for the timezone field. Consolidate?
• How can we best override the times to use the user's timezone if available? Obviously, we already need to do this in order to show the correct time next to the profile field.

[solhuebner]

Thank you for your new patch as this functionality is really needed.

[ravikatha]

I have recently created a plugin which has a similar functionality as this feature. The plugin is ​WP User Timezone.

To completely implement this feature, we can create a new plugin which provides the timezone selection somewhere in the user profile. The timezone thus selected can be applied to the WP User Timezone plugin using its wp_user_timezone_id filter.

The wp_user_timezone_id filter can also be used to apply any timezone id to the front-end interface.

Please go through it and give your valuable feedback.

[swissspidy]

18146.3.diff​ makes the patch apply cleanly again.

Previous comments are still valid and some additional work needs to be done to actually make use of the user's timezone.

[marcochiesi]

I agree with other users saying that this is a much needed feature.
Is there any plan to merge the provided patch into the core or pack it as a feature plugin?
Also, any plan to extend the WP User Timezone plugin by @ravikatha with the backend timezone configuration?
Thank you!

[ying-sun]

hi. as someone with limited experience and skill in modifying wordpress, is this patch something far enough along that i can try to use it, or is it only fit for experts as of now? as someone with a site where all users are registered and users are scattered across several time zones, and where one of the functions of this private site is for central calendaring across those time zones, this feature would be absolutely huge for me.

i would appreciate any and all guidance on this. this thread is the most promising thing my research has turned up so far. thank you so much.

[swissspidy]

@ying-sun Right now I would only use this patch on a development site, definitely not production. However, I'm still interested in moving this forward to a more stable state. I just haven't found the time yet to further pursue it.

[eArtboard]

+1

[Anticosti]

+ 1

[Rarst]

I definitely thought about user time zone making sense before. Also I think this wouldn't be too hard on technical side once we get through current push to clean up the Date/Time component.

However my more recent thoughts end up in a space of some serious UX implications. Introducing concept of user time zone implicitly in any place through the front end and admin immediately causes serious ambiguities.

User is setting a publish time on a post — are they using site time or user time?
User sees time output in admin — do they see site time or user time?
Users sees time output on front end — do they see site time or user time?

User locale works well because it's "obvious". User time is significantly more prone to cause errors in site operation and communication between site users.

On admin side I would guess all date picker workflows would need to be looked at and reworked for extreme clarity of what happens with user time zone in effect.

On front end side I am not confident we could just override outputs with user time zone. It might make sense to keep current function outputting site time, and introduce new API functions to output user time explicitly. Not sure.

[vstars]

Hello!

Time zone change according to user in the back office would actually help in more cases than just in multisites. Indeed, a company that has an international team and manages time related information with customers will find this feature very useful.

Best would be to be able to adapt timezone for WordPress, for back end users, but also for front end visitors.

Many thanks for all the great work and please keep it up!

Sincerely,

Vincent

Replying to westi:

I'm not sure what in core would use this information.

It sounds more like something that a specific multi-site install might add and make use of.

However, if we add per-user locale features to core then it would probably make sense to include timezone as well then.

[vstars]

Dear Rarst,

You reflexion makes sense and I agree on most of it.
There is however a way I think that would allow to bypass some difficulties.
Indeed, any time set by a user would be shown to another according to its time difference.
So, there could be a set time zone in the main wordpress, then all other times are located X hours ahead or after.

Therefore there would be only one raw information stored for time, all others would be displayed according to this "fixed time", ie GMT 0 for exemple, plus or minus a certain amount of hours depending on their time zone.

Does it make sense?

Have a great day,

Vincent

Replying to Rarst:

I definitely thought about user time zone making sense before. Also I think this wouldn't be too hard on technical side once we get through current push to clean up the Date/Time component.

However my more recent thoughts end up in a space of some serious UX implications. Introducing concept of user time zone implicitly in any place through the front end and admin immediately causes serious ambiguities.

User is setting a publish time on a post — are they using site time or user time?
User sees time output in admin — do they see site time or user time?
Users sees time output on front end — do they see site time or user time?

User locale works well because it's "obvious". User time is significantly more prone to cause errors in site operation and communication between site users.

On admin side I would guess all date picker workflows would need to be looked at and reworked for extreme clarity of what happens with user time zone in effect.

On front end side I am not confident we could just override outputs with user time zone. It might make sense to keep current function outputting site time, and introduce new API functions to output user time explicitly. Not sure.

[Rarst]

Replying to vstars:

Indeed, any time set by a user would be shown to another according to its time difference.
So, there could be a set time zone in the main wordpress, then all other times are located X hours ahead or after.

Therefore there would be only one raw information stored for time, all others would be displayed according to this "fixed time", ie GMT 0 for exemple, plus or minus a certain amount of hours depending on their time zone.

I am not concerned about storage, that is on the implementation side. I am much more concerned about user interface when users no longer operate in a single site's time zone.

If any one has practical experience with publishing workflows in such circumstances (or can point me to any open source CMSes that implement such) I would be interested to hear it here.

[vstars]

Dear Rarst,

Thanks for your response.

What concern do you have on the implementation side of front end visitors looking at the website at their own time zone ? The website would always operate at a single timezone, time-difference would be added to the main website's time.

Example:

• Front end visitor: [main time]+[front end time user difference]
• Back end user: [main time]+[back end time user difference]

Does it make sense?

Have a nice day,

Vincent

[johnjamesjacoby]

What concern do you have on the implementation side of front end visitors looking at the website at their own time zone

Where and how a datetime value gets mutated according to a user preference is highly nuanced.

There are endless examples of where a user with an account may prefer to see things relative not only to their current time zone, but even in their preferred date and time formats. Adding timezone support is simply the fist step of several.

It is not uncommon for a WordPress website to have multiple authors from multiple areas of the world. Depending on the difference between the site timezone and their own, it is possible to immediately see a time discrepancy when publishing content.

Allowing a user to set their own timezone allows for WordPress to reconcile those discrepancies in the UI, to avoid confusion around how content could be published either from the future or from the past.

Screen shot imminent of:

• Me living in Chicago
• My site being in Dawson Creek
• Me publishing a post at 11:55am my time
• Me seeing a post published at 10:55am without any indication why the time is off by 1 hour

[johnjamesjacoby]

In my second screen shot above, note that the "Choose a city in the same timezone as you" helper text is misleading in a multi-author environment, because this setting is for the entire site, not for any single user.

Me setting this to my timezone immediately introduces discrepancies for all other accounts outside of my timezone.

All of those settings probably belong in their own "Locale" page, along with the site language itself. Together, these represent a group of site settings that are regionally nuanced, and should serve as fallbacks for when user preferences do not exist (like in the case of an anonymous, guest, or non-logged-in account.)

• The site I write for is in Europe
• I live in Milwaukee
• European date format is day/month/year
• American date format is month/day/year
• They want their visitors to see dates in European format
• I want to see WordPress admin in my format

Also note that WordPress admin does not use these date or time formatting settings in many places of the admin-area UI, and that it is entirely up to the theme to either use the correct get_the_date() or get_the_time() functions, or manually look for and obey the date_format and time_format options themselves.

Adding a user timezone setting (in addition to date and time formats) is contingent upon us agreeing that it is important for the WordPress admin area to avoid confusion and adjust all date & time values according to them. We have agreed on user language so far, and in my opinion, the timezone is just as agreeable, as are date and time formats.

I believe it is less important that front-end or theme-side dates and times are adjusted in most circumstances, because most websites omit exact times from their publish dates as a way to circumvent the issue entirely.

[johnjamesjacoby]

Perhaps put another way, it was accidentally user-hostile & discriminatory to force everyone to publish to the web in English, so WordPress.org and thousands of volunteers have invested enormous effort into translating WordPress into dozens of other languages.

It is similarly, unintentionally, user-hostile to force users to adjust (or ignore) another person's date or time formatting, calculating 24-hour time vs. am/pm meridems , swapping months and days, etc...

---

It does not help that the WordPress admin area UI internally uses wildly different formatting on a screen-by-screen basis, so an audit should be done to identify all of them so they can be addressed uniformly.

Gutenberg and the new block-based editor handles this pretty well (kudos!) by taking the date and time formats into account and adjusting the inputs as needed.

---

In my experience, the reason this setting appears debatable, is because of a few different things:

• most sites are not multi-author
• of those, most do not span multiple timezones
• we've all gotten used to how bad it is, and either doing the math or not trusting the values

Which might be my way of saying that just because this may not be an issue for you yet, doesn't mean it hasn't been for others since forever. This is a legitimate design flaw, and deserves to be addressed. Perhaps it's worth breaking this issue into smaller, more manageable tasks, and combining them into a master ticket someplace else?

[rianjs]

Where and how a datetime value gets mutated according to a user preference is highly nuanced.

There are endless examples of where a user with an account may prefer to see things relative not only to their current time zone, but even in their preferred date and time formats. Adding timezone support is simply the fist step of several.

It is similarly, unintentionally, user-hostile & discriminatory to force users to adjust (or ignore) another person's date or time formatting, calculating 24-hour time vs. am/pm meridems , swapping months and days, etc...

How a moment in time is persisted, and how its displayed are two different things, and when those two things are kept separate in the software design, they're easier to mix and match.

For the most part, WP deals with moments in time. Those can be written down as UTC. A post, comment, etc. each have a moment in time when they're published, for example, and that moment is almost always in the past. There are some cases where WP has to think about moments in the future, but those are few and far between, and handling a case of tzdata changing what the future UTC offset rules are for a given IANA locale is going to be incredibly rare. (Time zones do change, but it's a relatively infrequent occurrence where population centers are.)

If moments when things are published are written down in the db with UTC timestamps, applying an IANA time zone *view* on that UTC time for each user (or falling back to the browser's assertions about time zones for unregistered users) makes it easy to display the UTC moment as a local moment. Further applying a formatting string to the local time is, again, a view concern, specific to the user, and fairly straightforward to implement.

[vstars]

Dear Rianjs,

Thanks for your words and explanation! I also had the feeling that this would seem easy to set up. Indeed, if the main time kept is the source of all time displays, then adding to it the user or visitor's time difference would be just like an add-on. The main time would never change, its display would though, according to:

• either the back end user's chosen time difference,
• or the detected front end user's time diffrence.

This could be expressed as:
Front: [WP set time]+[detected front user time difference]
Back: [WP set time]+[chosen back end user time difference]

Does it make sense?

[Rarst]

I'd like to reiterate that I am not against having user time zones. I am for having really really really solid workflows designed for that before storage is even considered.

And have no illusions, storage of time in WP is absolute disaster at the moment. It does not operate in UTC, it does not operate with normal Unix timestamps, it has two different and not entirely compatible time zone systems.

There is a mountain of work left on this before anything can be called "easy". Working on it. :)

Where I personally see this fitting into Date/Time component roadmap: after outstanding bugs are fixed, new API is added to work with unified timezone handling and real Unix timestamps, and around time we are looking into moving to canonical UTC for time storage.

[rianjs]

And have no illusions, storage of time in WP is absolute disaster at the moment. It does not operate in UTC, it does not operate with normal Unix timestamps, it has two different and not entirely compatible time zone systems.

Ha! I've worked on old, legacy systems, too. :)

[vstars]

Dear @Rarst

I really appreciate your participation there as I get to understand better what's behind all that. May I suggest that building this time zone flexibility feature is actually a great opportunity to reorder WordPress's storage of time?

This could have the potential to take wordpress to another level, and truly make it an global CMS ALSO on time functions.

I am grateful to be able to participate to this discussion, thank you!

[Lucanos]

+1

As @vstars notes, this is a terrific chance to recognise that WP has grown beyond its initial scope, with sites allowing users across the globe (and across timezones) to communicate and collaborate in systems built on the WP Core. Making the Core work on UTC, with a default site timezone setting able to be overridden per-user (or per-session for non-logged in users where we might be able to get their timezone otherwise) would be the ideal outcome.

[vstars]

Hi @Lucanos ,

Yes, you're right! This is exactly what I meant, but you used the best words. WordPress now has a global reach and influence on the web, so it's TIME that it allows TIME FLEXIBILITY!

;)

[vstars]

Would it make sense to begin by creating a standalone plugin that would allow such a thing a see the demands it meet before adding the function to core?

Does this type of work needs to change WordPress core's consideration of time?

Replying to Lucanos:

+1

As @vstars notes, this is a terrific chance to recognise that WP has grown beyond its initial scope, with sites allowing users across the globe (and across timezones) to communicate and collaborate in systems built on the WP Core. Making the Core work on UTC, with a default site timezone setting able to be overridden per-user (or per-session for non-logged in users where we might be able to get their timezone otherwise) would be the ideal outcome.

[dshanske]

I have done some work in this area outside of Core, after I got annoyed that a post I made in a different timezone on a trip got a bit muddled as to what time it is, and I've now set it so my posts on my personal site always show the timezone I was in when I wrote it.

I would welcome some increased sanity around this. The idea of only worrying about dates in UTC and converting them on the fly for display purposes would make life easier for all, but is going to be a pain for backcompatibility.

[asaturn]

I work for a large corporation that is currently switching our internal sites to WordPress. We have offices all around the world, and a local timezone setting is something I've been trying to code myself. This feature would be life changing, and really help sell WordPress as a suitable CMS for internal (and perhaps external) websites.

For now I'll continue to rely on my custom function, but I'm looking forward to this being adopted as an official feature.

[Rarst]

Replying to asaturn:

I work for a large corporation that is currently switching our internal sites to WordPress. We have offices all around the world, and a local timezone setting is something I've been trying to code myself.

It would be helpful to hear what are your needs on a real project and workflow/design consideration, if it's possible for you to share. :)

To keep everyone updated on general Date/Time component progress, we had finally produced a wp_timezone() function for unified time zone handling, regardless of WP settings. Waiting for merge. This will make Date/Time component a lot less broken and a lot more centered about working with real DateTime objects.

On other hand for the moment I've scrapped the idea of moving to canonical UTC, because additional feedback and research showed that it's not future-compatible approach. Since time zones can change arbitrarily in the future, it would be broken to rely on UTC for scheduling purposes. So fixing database time storage would need a different take.

[khill07]

Given the age of this thread I figured if anything was going to be added to the core to address this it was going to be a ways off. In the mean time I've created the following plugin to add a user timezone and off set the date displayed in both the public and admin section.

​https://wordpress.org/plugins/wp-utz/