ERROR on QXPD: --UNSUPPORTED RFC3339 date time string '2022-01-27T16:20:01'--

[Juan Jose Garcia Calvo]

Actually, I think the Qube people are wrong. The RFC3339 spec allows for dates without country offset, those should be handled as "Zulu" time or UTC. So I guess they skipped that part of the standard.

I've exported some DCPs with Davinci Resolve myself and did not run into those problems yet, maybe there is a discrepancy between versions.

Maybe you're right, I don't know the RFC3339 standard specs, but at least he have found why our QUBE refused to play this trialer.

EDIT: I just read the RFC3339 documentation and I see you CAN'T make timestamp without country offset: if you refer to UTC or ZULU hour, you must write +00:00 or "Z", but you can't leave it empty. That's what I understand.

About not having problems mastering DCPs with Davinci Resolve, maybe your DCP never has been played in a QUBE
Mine is the only one working in Spain.

Regards and thanks!!

JuanJo

[Mark Gulbrandsen]

Just curious Juan.... Is this an older Qube that is running Windows? If so, the Windows OS may be too far out of date to properly work. Windows OS's only seem to last so long because everything around it is advancing very fast.

[Juan Jose Garcia Calvo]

Hi Mark.

You need to update your windows in your computer as fast as you need to run new software, or you need to get new features, better graphics, more power to run games maybe…
but a cinema server like our Qube, running under Windows Standar 7 (an embedded windows version) always run the same software (a web based UI called Mama), and as far as DCI specs don’t change beyond the IOP or SMPTE (both supported), or 2K or 4K (both supported when it was ‘built’), so our system works more or less ok.

Luckly it run ANYDESK and TEAMVIEWER with no problem but I can’t access to some of newer webpages to download trailers (mega or wetransfer), but this is not a problem.

appearance is like a Windows XP, and it give me a lot of flexibility to access to all the files of DCP’s, SHOWS, KDMs, Cue’s files, etc…

the MAMA web interface is very easy to use, easy to schedule, easy to make shows (playlist) in a draw&drop timeline.
we like it

Regards!!
JuanJo

[Frank Cox]

Glad to hear that you love your MAMA.

[Juan Jose Garcia Calvo]

Glad to hear that you love your MAMA.

jajajajaja

[Carsten Kurz]

Actually, I think the Qube people are wrong. The RFC3339 spec allows for dates without country offset, those should be handled as "Zulu" time or UTC. So I guess they skipped that part of the standard.

While RFC3393 allows Zulu time, DCI/SMPTE does not:

'Timestamps shall not use 'Z' ('Zulu') time zone offset notation.'

I know that some servers tolerate Zulu time, others, as that Qube, seem to be stricter.

[Marcel Birgelen]

EDIT: I just read the RFC3339 documentation and I see you CAN'T make timestamp without country offset: if you refer to UTC or ZULU hour, you must write +00:00 or "Z", but you can't leave it empty. That's what I understand.

About not having problems mastering DCPs with Davinci Resolve, maybe your DCP never has been played in a QUBE
Mine is the only one working in Spain.

From the RFC:

date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
; rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset

partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset

date-time = full-date "T" full-time

The important part here is the "time-offset = "Z" / time-numoffset" part, so it looks you're right, you either need an offset or a "Z" to indicate Zulu time. I've not read the SMPTE specs, but Carsten seems to have done so. Apparently, a "Zulu" time offset notation isn't allowed. I don't know who came up with that idea, but any good standard apparently needs custom exceptions...

I've never really looked at what issue date DaVinci Resolve puts into DCPs before, but I've looked at the DCPs we've recently pushed out via Resolve (they're usually only used for a very small circulation, most are pushed out via Avid Media Composer) but they seem to put an offset into the IssueDate field in the CPLs. Maybe this was a problem with this particular version of Resolve or maybe it works because we're not operating on Zulu time here.

[Carsten Kurz]

I can only assume that, for a system that uses international time windowed decryption keys as a fundamental functional element, you simply want to be absolutely confident about local time and time zones, and thus you want timezone offsets explicitly being present.

[Marcel Birgelen]

Well, there is a bit of irony in that, isn't it? I guess that UTC has been one of the most stable concept when it comes down to how we represent time, just short of the concept of TAI. That;s why we keep most system clocks on UTC and many logging is also done in UTC. Everybody is able to derive the local time representation from UTC, whereas something encoded with an offset may come with their own sets of issues, as politicians around the world keep on changing stuff like Daylight Saving Times, time zone offsets and geographic boundaries of timezones themselves.

[Harold Hallikainen]

I really like the simplicity of UTC and especially the Unix timestamp. In my most recent product designs, I did all logging with a Unix timestamp and then converted to a local time display in the UI (in javascript). I did not have to deal with time zones, DST, or similar issues. The clock in my office / ham shack is on UTC.

[Marcel Birgelen]

In most projects I have something to say about, all timestamps are simply 64-bit Unix timestamps and everything is in UTC. Date calculations become so easy when there is a linear amount of seconds between timestamps and I keep laughing the naysayers in their face, every time they need to build difficult routines or SQL queries with inconsistent results to simply select records within a given time period.

I've gravitated towards TAI64 for a while, because I like that concept even more (it doesn't have those nasty leap seconds), but library support isn't always there, libraries need to be updated in order to keep TAI64 and UTC in sync once new leap-seconds get introduced and there are even less people that know about TAI64 than about Unix timestamps.