On Fri, 11 Mar 2016 22:12:55 +0100
Carsten Kurz via DCPomatic <dcpomatic@carlh.net> wrote:
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...
The idea is that the times in the KDM creation dialog are in the local
time of the target cinema. So if you say the KDM opens at 4pm it will
open at 4pm local time in whatever cinema you send the KDM to (provided
the cinema entries have the correct timezone offset set up).
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?
No, this is now wrong. The time window is in the target cinema's local
time. It would be easier for me in cases like this if that window were
modified to include an English message ("in the local time of this
machine") which you then translate into de_DE. Then when I open that
dialogue in English I see that something needs fixing. Are there any
other similar instances of extended translations that you can think of?
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?
That's the idea.
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:'
Yes.
Kind regards,
Carl
_______________________________________________
DCPomatic mailing list
DCPomatic@carlh.net
http://main.carlh.net/cgi-bin/mailman/listinfo/dcpomatic