I noticed v2.72 establishes timezones in the cinema database.
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:
<ContentKeysNotValidBefore>2016-03-14T12:00:00+11:00</ContentKeysNotValidBefore><ContentKeysNotValidAfter>2016-03-17T12:00:00+11:00<
<ContentKeysNotValidBefore>2016-03-14T12:00:00+02:00</ContentKeysNotValidBefore><ContentKeysNotValidAfter>2016-03-17T12:00:00+02:00<
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