Feature Request: Time zone for publication settings for each page / datatype

[VolodymyrMuzyka]

At this moment we don't have possibility define time zone for website publication, so if I have 2 websites in one, US and AU, at same server located at West US, my publish / unpublish dates will work as per server time (West US)

[VolodymyrMuzyka]

I would even say for each page / element. i.e. just add TimeZone to publication settings markup:

namespace Library.Common.Helpers { public class TimeZones { public static IEnumerable GetAll() { return TimeZoneInfo.GetSystemTimeZones(); }

}

}

    <KeySelector Label="TimeZone" Help="" OptionsKeyField="Key" OptionsLabelField="Label" Required="true">
      <KeySelector.Selected>
        <cms:bind source="TimeZone" />
      </KeySelector.Selected>
      <KeySelector.Options>
        <ff:StaticMethodCall Type="Composite.Plugins.Functions.WidgetFunctionProviders.StandardWidgetFunctionProvider.String.SelectorWidgetFunction,Composite" Method="GetOptions" Parameters="&lt;SelectorOptionsSource KeyFieldName=&quot;Id&quot; LabelFieldName=&quot;DisplayName&quot;&gt;&#xD;&#xA;  &lt;TreeNode&gt;&#xD;&#xA;    &lt;f:param xmlns:f=&quot;http://www.composite.net/ns/function/1.0&quot; name=&quot;Options&quot;&gt;&#xD;&#xA;      &lt;f:function xmlns:f=&quot;http://www.composite.net/ns/function/1.0&quot; name=&quot;Library.Common.Helpers.TimeZones.GetAll&quot; /&gt;&#xD;&#xA;    &lt;/f:param&gt;&#xD;&#xA;  &lt;/TreeNode&gt;&#xD;&#xA;&lt;/SelectorOptionsSource&gt;" />
      </KeySelector.Options>
    </KeySelector>

and that's it. Should be very easy to implement.

[mawtex]

Should be very easy to implement.

Well, we do accept pull requests ;)

I guess your code here will only create a selector field, and then this would need to be wired up to the logic behind the scenes, and this would have to be done on a "per feature" basis. If time zone info makes sense for publication times, I guess it would make sense for most date/time selections?

I'm wondering if it would make more sense to isolate this to the DateSelector field - expanding this field widget, so it (upon expansion) allows for a time zone selection?

When saving, the date time emitted by the widget would be calculated acording to the selected time zone (towards the server time zone). This would add time zone support all over the system. Changing the timezone would show the current date time value calculated for the new time zone.

Usability Second thing that would be nice to take into account is to find a way to ensure users have to care about this selection as little as possible. So finding a strategy where this selection is "most correct, most of the time". The challenge being that a user may be managing content for different locations.

A few strategies and their pros / cons:

• Always use server timezone. Easy to implement, but will force user to continuously change the field, when working with content for other time zones.
• Have a user setting (for instance as part of the "Regional Settings" dialog). Will allow user to choose a global time zone, but will be annoying when managing content in another language / locale.
• Have a setting attached to a website / language. Will work for content located below a website, but not global data and we would need to route the info in a ton of places (tough to implement).
• Have an extra field of the "Languages" elements (system perspective) where a TimeZone can be set for an element, preset to the selected locale. Whenever the DateTime widget is showing a date, this setting would be used. This would require almost zero user interaction, but it would also give the impression that C1 is TimeZone aware in relation to languages, which would not be the case (this would simply influence the Date Time widget). *)

Another thing worth addressing is if we should annotate collapsed date fields with time zone info (very informative, but also more noise in the UI).

*) One issue with TimeZone is that you can't "switch" to a time zone, like you can switch the CultureInfo for a request / thread. So code influenced by a time zone setting would need to be addressed one by one - so giving the impression this is handled globally is no good.

How to handle pure dates? Going down the route where time zone become part of a date time selection, create another small issue; how to handle date only selections. If a user in time zone A sets a date, I guess it makes sense we recalculate this selection (some date, midnight) into the server time zone (ex. some date, 3AM). And if a user in time zone B edits this, I guess we would need to either have time included (although this is a pure date selector), or convey that the date shown if for another time zone. Here identifying this original time zone is probably impossible, as time zone is not persisted as part of a datetime.

[burningice2866]

My 2 cents;

Using server timezone is generally a bad idea in the new era of Cloud Hosting, where ones code could potentially by running in both a random timezone or in many timezones at once.

Like with numbers and other "raw data vs presentation" differences, storing dates should generally be done in UTC and the necessary conversion is then done when a date is being used.

Lets say that we are creating a News Item. The correct way is to set the CreationDate field in UTC, and only when you're presenting the date as a string on the website, do you do the conversion into a local time. What the local time is should depend on either a 1) C1 Installation setting, 2) a website setting per website, or 3) a user-setting if the website supports users to log in.

• By creating a C1 installation setting, you break the dependency between the server and the C1 installation.
• By creating a per website setting, you enable the scenario of hosting multiple website targeting different regions in the word, which is even better.

Both the mentioned scenarious doesn't add any new C1 Console complexity towards the editor, which in most cases doesn't know or care about timezones. Instead there should be added new C1 specific extension methods on the DateTime type, which enables the developer to convert from UTC to C1LocalTime depending on either the installation setting, or the website setting. Since we're always in a "website context" when rendering a page this works fine for Global data as well.

The DateTime widget in C1 should as well convert between LocalTime and UTC when respectively showing the data in the Console and saving it on the datatype, but as mentioned, the editor doesn't need to be aware that dates are saved in UTC.

• For C1 Console editors there should be a Timezone setting, like console language, so DateTime widget can show LocalTime correcty for a given editor.

[VolodymyrMuzyka]

Marcus - right, I wish I had more time to help :) Now I'm just thinking forward for scenarios we will be facing rolling out 39 + 14 regional sites.. In our case (1 site = 1 language) I can make workaround more or less easy.

You wrote excellent copy. Here my two cents, to keep it simple..

1) TimeZone in DateSelector - better keep it separated. Because - it's will automatically give you 2 TimeZone fields for Publish and Unpublish. With separate field you can see immediately which zone it is and less noise for UI. Plus we have drop-down already - no need to invent new widget and handle extra logic..

2) Server time zone is default and defined in System => Languages. This first default global setting and will work for datatypes and pages.

3) We can override default via site settings (second default)

4) Two global defaults could be overridden by setting individual item time zone. Here the trick to avoid UI hell - just remember last entered timezone as we do for Save / Save and Publish.

Pauli - I agree with most in your text, but approach - "conversion is then done when a date is being used" is good for datatypes ONLY. We can't control pages.

[burningice2866]

@aeont You're correct that you can't control Page publishing at the moment, but if one were to implement any of this, lets say Installation and per-website setting, the Publishing/Unpublishing code inside the C1 core would of course be updated accordingly to take such new settings into account.

[mawtex]

We already store date time values in UTC so that part should be good.

There is no guarantee that date related operations happen in the context of a website. Use cases could be "user manages global data", "data is exposed via non-page request (ex WebAPI)", "a scheduled task should launch". Also, there is a lot of situations where - to determine a website - we would need to pass website info along, for example "edit a function on a page, set a date time" - doable, but would requiring that the concept of "currently edited page" flow deep. I would say a website based approach is a lot more work and will only work in a limited set of situations.

On the other hand there is already a objective relation between time zones and CultureInfo. For most countries, we can automatically determine a time zone based on CultureInfo and for countries spanning multiple time zones there are very educated guesses (but UI to select one is still needed, hence the "Languages" suggestion). Any website will relate to a CultureInfo and would thus relate to a time zone.

Only place where choosing website above CultureInfo would save the day is a use case like "we have different websites, all for the "en-US" culture info, but for different cities (time zones)". In this situation a user managing content across cities (time zones) would have to bother using the time zone selector.

Or am I missing some other clear advantage of using "website" as the way to find time zones?

[burningice2866]

If you have operations that doesn't happen in a context of a website, then you can't infer the Timezone either based on the language of that website you're not in a context of. Or am in missing something?

[VolodymyrMuzyka]

..was distracted and forgot press "Comment" so @mawtex was first..

@burningice2866 @mawtex what if just simplify everything to "per website".. in real world 1 website = 1 timezone. So in this case everything is simplifies to:

1) add timezone to website settings (System => Url Configuration) to make page publishing controllable 2) data item considered published within website timezone. 3) operations that not in a context of website could be solved - because it's custom output anyway, so it's 100% controllable in the way developer want it to be.

[mawtex]

The moment a request pops in we are able to attach if to a data scope (which contains a CultureInfo) - the default is configurable via "Languages" and it follows the general data/language logic. For admin users in the UI there is also an active data scope.

Just to throw more into the mix there are people around me suggesting time zone should be a "per admin user" setting. Which would only address admin situations (and be flexible enough to both fix anything and create ample confusion).

[VolodymyrMuzyka]

I would not over-complicated it adding "per admin user" - it's will be confusion.

[burningice2866]

Thats the fall-back datascope, the default language for the installation... hence the C1 Installation setting for timezone as well, which would dictate what timezone to use as fallback - when there is no website context available.

The timezone per admin-user is a setting to convert from the stored UTC to a localtime for that editor when editing pages or creating a news item and manually setting a date. The date the editor is seeing or selecting is local to them, but is saved in UTC based the timezone setting for that user.

Such a setting is not needed, but would otherwise require that the editor knows what timezone a given website is in when selecting ie. a publication date, so they don't accidentally select a wrong time because they are sitting in Copenhagen but the website they are editing is in Greenlandic timezone.

[VolodymyrMuzyka]

How it's will live with "Moving url configuration out of core product" ?

[DBailey635]

Sorry @aeont , I should have added a note here too.

If you need somewhere to set a site-wide default location and time-zone value for publication dates... the hostnames section would be a good place to put this preference/setting. However, the commit referenced above removed this bit of UI.

[mawtex]

Closing this since Time Zone Support has been introduced - if there are still interest in changes in this area, please create a new issue, taking Time Zone changes into account