Configurable Timezone

[halfdan]

Ghost should allow the user to set the timezone of their blog. Setting the system time in node.js is not a viable option.

Solution(s)

• Moment Timezone provides a nice extension to the moment.js functionality already in use.
• Timezone

Configuration

1. The configuration could happen in the config.js, but that might not be flexible enough.
2. Admin Settings could be extended to show a simple dropdown with all available timezones and store the setting in the database.

Related Issues #907, #814

This ticket should serve as a place for discussion on how timezones should be implemented in Ghost.

As for implementing it: I raise my hand.

[ErisDS]

This is definitely a setting which requires a UI and not a config option - config is for environment specifics only, and should basically be where all the stuff that scares non-techies lives. All the features for configuring how Ghost works live in settings.

My main question is, is Moment Timezone smart enough to know about Timezones which change? So can I set myself to 'London' and get GMT / BST correctly? It looks like it is.

The next thing is to ensure we are aware of all the places this is needed and all the things it effects. As far as I'm aware, it should affect output only - i.e. how we render dates to users, not the storage?

[jgable]

I wrote walltime-js a while ago to do JavaScript timezone stuff properly. Moment Timezone looks very nice, and it looks like it takes a lot of the same approaches as my library, plus it's just native JavaScript which I'm glad to see.

I would definitely sign off on Moment Timezone based on the extensive tests alone.

[ErisDS]

I think this would be a good issue to get into 0.4

[halfdan]

Moment Timezones provides a data generator that lets you choose which TZs to include. Should we simply include all timezones by default or only provide a subset?

[ErisDS]

I'm pretty sure an enormous list of all of them is gonna be bad UX: http://ux.stackexchange.com/questions/21409/how-to-make-selecting-a-timezone-more-user-friendly

[ErisDS]

The more I think about this, the more I wonder if having a list / setting is the right approach at all.

We have 2 groups of users. The person writing the post, and the people reading it. The person writing the post will want to see everything in both admin and blog appear in their timezone. But what about the readers? Should they see dates outputted according to their TZ, or the authors TZ, or the TZ the blog is set to?

E.g. I write a post at 11am BST, which is 10am GMT/UTC. I expect the published time to be 11am. However, when the americans wake up and see my new blog post, it should probably say something in the region of 3am - 5am for them depending on which part of America they are in. When I look at it, it should still say 11am.

So, other than knowing that I, the person who wrote the post, is in BST, what help does setting blog to a TZ give us?

I think we need to have some more discussions around what the current problems actually are, before determining a solution.

[halfdan]

The author needs to be able to set a publish time that matches his timezone - so there definitely has to be a setting in the backend in order for Ghost to figure out what the author means by "11am" (should it be available at 11am UTC or GMT+3 or UTC-7?).

For a reader it will be enough to just show the timezone the author is in (e.g. Published at 12am UTC). I would even argue that it's not important at all, see e.g. h-online, slashdot, wired. Wired doesn't even display publish times.

---

Regarding the list I think we could boil it down to just show all UTC offsets without the country specific lists (i.e. UTC+1, UTC+1.5, etc.).

[ErisDS]

Why make the author specify? Why not just ask?

[JohnONolan]

I'm a big fan of eliminating any concept of time-zone whatsoever from a UI POV. Time-zone is based on location, and location is something which makes much more sense for the user to define.

There is almost no use-case that I've come across where timezone is more helpful than location. Eg. What time is it in Chicago right now? - vs - What time is it in PST and does that include +/-1 DST?

If we can give a blog a concept of location as a setting, we can both determine the timezone from that data, as well as do more interesting things with that data. (eg. geographic / local search). The only additional requirement is implement locations with some form of typeahead to make sure we the data is standardised. (ala Facebook's inputs)

The same concept of location is also relevant to individual authors, where timezones can have interesting back end workflow implications (editor/author overlap + post scheduling) over front end implications (output).

[jgable]

Based on the data in the Moment Timezone list we could do a more friendly name search for the timezone by area. It even has lat long values so we could use JavaScript location services to make an educated guess on first load?

[halfdan]

@ErisDS I usually write my posts in English and like to have blogs published when most native speakers are awake. I usually set the TZ of my blog to UTC or even EST. This way I can specify publish times in the timezone of my target audience.

@JohnONolan I like the idea of eliminating timezones from the UI but don't really understand the implications you are making. How would it work with an author in New York and an editor in San Francisco?

[feriancek]

I would think the reader only truly cares about the date a post is published, and the order posts are published in the run of a day. The specific time a post gets published is only a concern from the admin side, both for collaboration with other writers, and scheduling when future posts go live.

Treat the admin list like a timeline. When writing, all that really matters is the choice of "Publish Now" or "Publish Later", I don't want more UI clutter on the writing page. Once that's chosen, the specific time can be decided from the post timeline view, where the UI allows more information to be expressed: "What time of day did I publish last week?" Changing the publish date/time can visually change the order the drafts are listed in, making it clear that my article goes live an hour after a draft by my co-author.

[billwscott]

Where did this land? It seems really odd sitting here on Christmas Eve, publishing my first post and it displays that I published this on Christmas day. This needs to work just like it does in blogger or wordpress -- that is the author should not have to think about it. Providing a default setting so that the post is set to publish in that timezone would be a good start. Right now I have no control over it.

[hswolff]

I'm big +1 on implementing the ability for a user to set the timezone of their Ghost blog.

I've already been bitten by this user experience mishap.

I published a post and shared it with my friends and they all wondered why it said it was posted a day in the future. Really un-expected experience from a user's point of view.

[ErisDS]

OK so, I would really like to get this into 0.5, there are a couple of little implementation details I'd like to wrap up, so I'm just gonna jot down how I think it ought to work and then if there are no major problems with it I imagine it'll need splitting into a couple of issues...

---

The UI

The common UI for this is a dropdown list of timezones, which is fugly, but I guess there's not a great deal that can be done without a great deal of work.

I'd like to at the very least use the common format:

(GMT+/-##:##) City1, City2
e.g.
(GMT+05:30) Chennai, Kolkata, Mumbai, New Delhi

but I am wondering if it wouldn't be a nicer UI if it said:

"What time is it where you are?"

and listed the options like:

* 17:42 London (GMT)
* 18:42 Amsterdam (GMT+01:00)

I'm guessing that there is a reason why this UI isn't common, other than the fact it's likely to get a few minutes out of date, to do with things like BST where timezones move around and therefore the current time is not a clear enough indicator of which rule set to follow.

A third idea is to still show the current time (with a live update) as Ghost believes it is, with the normal dropzone nearby or accessible via a button to change the current date (click date & open in a modal?). This might be a nice iteration for later :)

The list to show

Here are 2 example lists:

• Twitter: https://gist.github.com/ErisDS/873603c769b7c4d15f43 (141 options)
• Slack (my new fave thing): https://gist.github.com/ErisDS/7524f98965c5739d20fd (95 options)

As far as I can see, there are ~30 unique options in the lists, but again, I guess there must be reasons for showing so many duplicates - I assume again because some places have different rules for how and when the timezones change through the year?

Here's an example:

<option value="Europe/London" selected="">(GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London</option>
<option value="Africa/Casablanca">(GMT) Casablanca, Monrovia</option>

It seems that Casablanca has a month between June/July where DST doesn't apply:
Casablanca vs London

I guess I'm lucky enough to not have had to deal with these complexities before, so I'm very keen to have some insights from someone who has! Nonetheless it seems like someone needs to spend some time researching and determining what a good starting point for the list is, as I believe the shorter the better, although I guess it doesn't matter too much as it's not something people will have to do often.

Rolling out the setting

The setting needs to be per-blog rather than per user, and so should exist on the Settings/General screen. It will be used to display the dates & times on blog posts in the given timezone both on the admin UI and on the blog itself.

As it stands we use the {{date}} helper which hooks into moment to do this, so I guess that is where the main changes need to be, but we also need to bear in mind that the helper currently exists twice: once in /core/server/helpers/index.js for server side rendering, and another in /client/helpers/index.js for client side rendering - it would be super great to be able to share this code, but it may be that they need to work slightly differently as they reference different versions of moment - not sure here probably more on this later.

Dealing with existing blogs & sensible defaults.

Existing blogs don't have a concept of timezone, everything happens in the server default timezone which is most commonly UTC.

I think the base default should be GMT, just because everything else is considered in terms of +/-, so you can go up or down from there - this shouldn't cause any change in functionality for existing blogs.

On the settings page, the closed dropdown will therefore show GMT, but on clicking the dropdown to open, rather than opening to GMT, if there is a better default that can be determined from the browser, it might be a good idea to scroll to that setting?

Thus setting timezone becomes a matter of clicking the dropdown open, closing it because it sensibly chooses the right thing, and hitting save :)

---

...Right that's my brain dumped. Any thoughts?

[ErisDS]

Does no one have any experience of this that they'd like to contribute?

[javorszky]

Hm, moment.js timezone has pretty much everything we really want I think, it's a matter of including this in the UI.

If you want, I can take a stab at it. Currently unfurling 1601 though, so that could be PRd.

[ErisDS]

Yes moment.js timezone has the core functionality, but it also has like 300+ timezones to choose from. This is also 2 or 3 different issues I think, I'm just looking for feedback at this stage before dividing it up - but I guess it's tl;dr 😉

Will divide it up and perhaps generate conversation on the different parts.

[javorszky]

So...

• Figure out which time zones do we actually need
• Implement the chosen few

Right?

edit: man, it sucks not being able to put tickboxes here...
edit2: @halfdan can rtfm, I can't... thx 👍

[halfdan]

You mean like this?

• @javorszky knows how to create tickboxes

https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments

[ErisDS]

I've broken it down into 3 tasks to try to make it beginner-friendly, as we are seriously lacking in beginner / newcomer level tasks in 0.5 at the moment:

• Determine the best list of time zones for use in Ghost Determine the best list of time zones for use in Ghost #2359
• Add timezone dropdown to settings Add timezone dropdown to settings #2360
• Use the new timezone setting in the server side date helper Use the new timezone setting in the server side date helper #2361

[iarico]

Relative Time hasn't been mentioned in this thread about time: is relative time (aka "time ago") an option at any level? It sounds like it could solve concerns that @JohnONolan, @ErisDS and @halfdan raise. Moment.js doesn't have relative time in the core, but there is a plugin.

I noticed as I read this entire thread about timezones that every timestamp on this Github page is relative. Are [some types of] timestamps dead, in need of burying?

[ErisDS]

Relative time is already used in the admin, but is not common on the frontend of a blog. The theme API has the option to display either.

Regardless of this, relative time still has to be set and calculated as relative to something, that thing is a timezone. This issue is about ensuring we have that value and can calculate times correctly, whether they are relative or absolute.

[zchrykng]

@TheLoneCuber It appears that moment does have it relative time built in, the mentioned plugin is only for matching twitter's formatting.

The pull request here might help with the technical parts, but it has not been merged yet: moment/moment#1459

[javorszky]

I am going to drop a bomb on this.

After a bit of deliberation and thinking and looking at examples, and whatnot, I am on the side of eliminating TZ's entirely from being a setting that the author can set.

Why stuff will work w/o TZ setting

• We already know the UTC time of everything that's happening. Every language that I have ever encountered has a function call that returns the UTC timestamp of now().
• Once we know the UTC timestamp of any object, we can push that to the client side, and let the client side javascript figure out what to do with it. The way BBC handles this is that it displays a different timestamp of the same article depending on where you're viewing that. The browsers are aware of which timezone they are in (call a new Date(); in the console of your browser, it will include your TZ in there. I changed mine from UK to Chicago, IL, and it correctly followed me).
• Once we have the UTC timestamp (as provided by the server) and the local timezone (as provided by $browser), we can easily display local time to whoever, which I assume is the intended behaviour.

Why stuff will break with TZ setting

• You set your TZ to say UTC+11. Your reader from UTC-4:30 comes to read your content. Reader does not know where your blog is (nor necessarily care). If you published an article a few moments before your reader might arrive there, the published timestamp can be 15 hours in the future for the reader.
• Even if reader knows the blog is in UTC+11, what does the displayed published_at time mean? Is it in the reader's TZ? Is it in the blog's TZ? Remember, it's not obvious, because BBC will display local TZ time.

Moving forward

I propose to get rid of setting a TZ setting, and use UTC timestamps everywhere, and let the client side figure out what to do with it. It could be a helper.

Thoughts?

[javorszky]

Also: http://www.vox.com/2014/8/5/5970767/case-against-time-zones

[ErisDS]

Closing all the timezone related issues with the label later this is stalled. Will reopen when we're ready to attack this with a plan.