You have been asking for it and we are on it!
We are working on adding support for local timezones. As this spans all areas of the doc we want to make sure we are doing it right and need your help. Please reply here if you would like to get early access to this feature and provide feedback. Having teams that work in different times zones would be super helpful too!
Thank you!
6 Likes
Hi, my team is spread out across Canada and we are anxious for timezone support,
let me know what we can do to help
j
1 Like
I’m in. I can gladly test this on my documents.
1 Like
Sign me up. I’ve been waiting for this feature
1 Like
Yes please. Game changer for us UTC+12’ers.
1 Like
Yes! Live in China, UTC+8. And need customizable date and time format.
1 Like
Spain here, glad to help.
1 Like
Finland, please sign me up, urgently need this feature!
1 Like
That sounds great, please sign me up as well! thx
1 Like
Please sign me up for the beta!
1 Like
Yes please! Many thanks.
1 Like
I alsĂł would like to test it. For me it is important functionality.
1 Like
Would also love to take part, I’m in CET, but need to do planning for things from the west coast of the US to Vladivostok, so it would be very useful for me!
1 Like
I’m in Australia - happy to test this.
1 Like
Thank you for your enthusiasm and want to help. We are excited to get this going too but have run into a few hurdles and are working through it. I have you on the list and will be asking for your input in the near future
It’s obviously a bit annoying to get feedback when the feature has been developed already, but I would want to raise one point about the timezone support that I hope is somehow resolved.
My point is that there are times when timezone information should be used and times where it mostly should not.
If there is a calendar meeting that is attended remotely from multiple timezones, it is obvious that every user should see the event in their timezone (which might be the browser timezone, but might not be!). Same for rocket launches, game release times, deadlines etc.
However, if there is an event that is mostly local and constrained to a physical space - such as a gig at a local venue, opening times for a restaurant, or plane take-off time - then timezone information is beneficial to be present, but the time should always be presented in local time corresponding to the physical location of the event. It would be very confusing that when travelling abroad and checking that I want to make it to a restaurant when coming back to my home country to see the restaurant opening times in the timezone of the country one is travelling in. Or seeing “Doors open at 18:00” for a gig, only to notice when getting there that they actually open at 20:00 local time.
A special category of these would be events that happen at the same time according to local time zone across the world - such as earth hour - where there really is no timezone information for the event - but that is such a corner case that that probably doesn’t need to be respected.
As for dates specifically, with no time attached, I think the default should be to handle them timezone agnostic. If a calendar shows that christmas eve is 24th of December, it would be really confusing to see 23rd of December there in some timezones. Same for almost all dates one can think of.
For the technical side - ISO-8601 specifies dates and timezone information pretty exactly. For example, “2019-02-27” is a timezone agnostic date, which is not local time or any other timezone, but specifies the date only - where as “2019-02-27Z” specifies the date in UTC, which then delimits a strict time duration from 00:00 to 23:59 UTC. Same thing for times “2019-02-27T10:37:18” is time zone agnostic, does not specify which time zone it happens in so does not mark a point in time, where as “2019-02-27T10:37:18+02:00” specifies a point in time, that is exactly equivalent to “2019-02-27T08:37:18Z”.
It would appear that currently, under the hood, you store both dates and datetimes as seconds from epoch. This is very unwise in the long term, as leap seconds are added at unspecified times and hardly no time libraries properly have a record of every leap second addition. The end result is that epoch times in history can be one second or several seconds off. About the only consistent way to represent a point in time that does not change is representing it as ISO-8601 - but you must remember that “2016-12-31T23:59:60Z” is a valid time (seconds at 60). And obviously seconds since epoch is impossible for times without timezone information as they do not represent a point in time.
And a final note - please remember that the week does not start on sunday in most parts of the world 
Keep up the good work!
2 Likes
Not sure I agree… think about events that might be live streamed? I think it’s more a job for the person building the doc to explain this.
I think the most sensible approach would be to use sensible defaults also have a User().UTCOffset number which is added to the user (and potentially an Time.Timezone.UTCOffset number). Then, in case as a doc builder you want to show in a specific TZ, you can use the difference in UTC Offsets to do whatever maths you need to to handle the display for the user.
Joe
There are obviously special cases, with live streaming and such - but if you go to Ticketmaster and see a listing of shows, do you expect to see the gig starting and ending times to be in the timezone where the gig is located at, or the timezone your browser happens to be using at the time?
1 Like
Yep, agreed. I suppose my point is that as much control as possible should stay with the doc creator. I believe that most events will have an absolute start time and it would make the most sense to display this in the user’s local timezone, but enough options should be made available to allow a creator to hack together a tool that always displays (for example) the time in the timezone the event was created, or the time in London, or through some other logic.
Joe
2 Likes