Please check your cinema database, as per default it seems that DCP-o-matic will update all cinema entries with UTC as default. That could bring trouble if you are already  creating KDMs within a time zone with a large offset from UTC. So go through them one by one and get them right.

Carl - I expected the time window in the KDM creation dialog to change per local UTC offset variation when I select a screen within a cinema with different UTC offset. I know it is not a must, of course.

But maybe it would be helpful to indicate the UTC offset when selecting a specific screen?

Hmm, I just noticed it is possible to create multiple KDMs at once by selecting multiple screens simultaneously, so that wouldn't work, as there can be multiple different time zones involved...

Well I DO know it is not a good idea to create KDMs with very short time windows anyway, still it is now becoming a bit complicated to actually know what actual time frame is created because the offset is 'hidden' in the database. 

Hmm, maybe you can display the UTC offset after the cinema name in the list? Selecting a specific screen would always make the UTC offset visible because of the list expanding necessary to select that screen.

For clarification, I extended the german translation of 'Timing' in the KDM dialog to 'Time window (local time of THIS machine!)' a while ago.

I assume this is still valid (but not exclusively now)...and what the time zones now do is to adjust the displayed time window to the UTC adjusted remote locations?

That is, if I choose a time frame of 03/14/2016 12:00 to 03/17/2016 12:00 there, and create a KDM for a cinema with an UTC offset of +11, it WILL result in exactly that time frame of 03/14/2016 12:00 to 03/17/2016 12:00 AT that specified location?

Seems I need to adjust OR extend that translation again ;-)

Well, whatever, I just played around with it and adjusted some known cinemas with fictional UTC offsets (+11 and +2) and created two KDMs simultaneously.

The indicated time frame of: 03/14/2016 12:00 to 03/17/2016 12:00 resulted in the following KDM details to be created:

When I check my database of KDMs we received over the years, there is a wild mix of time frames given either with UTC-offset=zero and absolute time adjusted, or with UTC offset. So it seems both methods are used and both work.

When I send these KDMs as email, the time window is expressed as local time in the email text, so that is also what the local recipient expect, as he will always refer to these time frames in local time:

'Der Schluessel ist vom 2016-03-14 12:00:00 bis zum 2016-03-17 12:00:00 gueltig fuer:'

- Carsten