Welcome to the Panopto Community

Please note: All new registrants to the Panopto Community Forum must be approved by a forum moderator or admin. As such, if you navigate to a feature that is members-only, you may receive an error page if your registration has not yet been approved. We apologize for any inconvenience and are approving new members as quickly as possible.

Meaning of StartTime in the Session class


I have been using the SOAP GetSessionsList and GetSessionsById methods, which return a list of or a single Session object respectively.

I have noticed that on our Panopto instance the StartTime (defined in the docs as the time the session started recording in UTC) often differs from the Date attribute in the GUI session settings, even when accounting for the timezone. Specifically, the StartTime is usually a day or so ahead of the GUI date. I should add for completeness that the session media has been uploaded from Collaborate using REST/SOAP APIs.

Is there a reason why these two datetimes are different? Also, do the APIs store somewhere a property whose value is the same as the Date attribute in the GUI?

Thank you



  • Options

    I can't answer that question directly but what I can tell you is the Start Time in many of the Panopto reports is the Date listed in the UI, not the actual date of creation.

    That Date field is editable and can be changed by users. If someone changes the date in the UI, you can have a situation where there are views of content which happen before the content is even created.

    I seem to recall when I wrote an app to migrate a bunch of content to Zoom, I wanted to set that Date field to match the start time of the Zoom recording via the SOAP API but I couldn't make it work. (I suspect it's because I'm not a programmer and was too stupid to figure it out so I just gave up.)

    You might be better served opening a case up with Panopto support.

    Sorry I don't have anything more to offer.

  • Options

    Hi Chaz,

    Thank you for your comments. Indeed, I had thought of opening a case but wanted to pick the community's brains first in case this was an issue for others too.

    The specific problem I'm having, regardless of whether Date differs from StartTime is when I try to use the SOAP GetSessionsList method, and set a date range with the StartDate and EndDate properties. Judging from the StartTime property of the results, it appears that the method does not search on StartTime but rather on some other property, which I can't find.



  • Options

    The discrepancy between Dates in the UI and the actual Creation Date (i.e. when the session was uploaded) is an issue across the platform, most notably in the variety of System Reports that show dates but also now with Retention Policies that reference the Date Created. If your Institution has ever imported content into Panopto via their Professional Services, you will have run into this issue because Panopto matches the Date against the Recorded Date of the source content. In addition to opening a case, I think it would benefit the Community if a Panopto rep posted some information on Dates here in the Forums. That could be a link to existing documentation - although I don't see anything with a definition of date - or a rundown of what "Start Time" refers to across the System Usage reports that contain that column (e.g. Sessions Created or Edited, Session Usage, System Session Usage).

  • Options

    Hi All,

    I spoke with a member of our Dev team, and they stated that the Start Time should be the time that the session started recording and the Creation Date is the time the session is created. For a scheduled recording, the Creation Date is the time the session was created and Start Time is the time it actually started recording.  The Date in the UI and the Date returned in 'Session.StartTime' should be the same, but note that the API always returns things in UTC and the UI uses the site's time zone.

    The Date shown on the session list pages is:

    •  If there is at least one primary stream on the session, the minimum start time for a primary stream
    •  If there are no primary streams and at least one secondary stream on the session, the minimum start time for a secondary stream
    •  If there are no streams, but the session is a scheduled recording, the start time for the scheduled recording
    • If there are no streams and no scheduled recordings, the session's scheduled start time
    •  If none of the above found a time, it's the time the session was created

    If there are places that the UI and API are returning different results, they indicated that it would be helpful if you could provide an example, as these results should be the same. If this is the case, please feel free to reach out to me directly and I can send it to them directly for investigation.

    If there are any more questions, please feel free to ask - we're always happy to help!

    Best wishes,


  • Options

    @Caitlin McCabe OK, thanks for that reply. I'm perhaps branching off the purpose of the OP's topic here, but what concerns me about the "Date" field in the Overview section of a session in the UI is that it is editable. If that is being used as the basis for a retention policy, then it can be manipulated to exempt sessions. I was also told that a retention policy based on "Creation Date" translates to the most recent of either the actual Creation Date or the StartTime. Is that true? Also, FWIW, Creation Date doesn't really surface anywhere in the UI unless you're looking at the Log of a session.


  • Options

    Hi @Jaime Bermudez,

    I went back to the team to ask your questions, and received the following reply: "Yes, modifying the "Date" field in the UI can cause sessions to be exempt from a retention policy.  Additionally, yes, a retention policy based on "Creation Date" uses the most recent of either the actual Creation Date or the StartTime. The assumption is that if you schedule all your remote recordings at the beginning of the semester and have a retention policy based on creation date, you want that to be based on when the recording actually happened, not when the scheduled recording was created at the beginning of the semester."

    If you have any additional questions, please feel free to ask.

    Best wishes,


Sign In or Register to comment.