SCORM time limits: max time allowed

Can SCORM enforce a time limit?

SCORM can carry a time limit, but it does not enforce one. The SCORM max time allowed value is written in the package manifest, and the course reads it at runtime as cmi.max_time_allowed in SCORM 2004 or cmi.student_data.max_time_allowed in SCORM 1.2. The course itself must watch the clock and act when time runs out.

That split surprises people who expect a setting that makes the LMS close a timed assessment. The specification gives the LMS one job here: hand two values to the content when asked. What happens when the limit is reached is the content's decision, guided by a second value that says whether the learner should be sent out or allowed to carry on. If the course never reads either value, a time limit in the manifest changes nothing a learner can see.

The SCORM max time allowed elements

Two data model elements carry the limit, and both versions of SCORM have the same pair under different names. The content reads them through the API calls described in the SCORM API explained.

Read-only is the important row. The content cannot set, extend or clear its own limit. A SetValue call on either element fails with an error, and the value the LMS holds stays as it was.

The limit applies to the learner's accumulated time in the attempt, not to one sitting. A learner who spends twelve minutes, leaves, and comes back has twelve minutes less. To work out what is left, the content reads the time already recorded and adds its own running clock for the current session:

GetValue("cmi.max_time_allowed")    → "PT30M"
GetValue("cmi.time_limit_action")   → "exit,message"
GetValue("cmi.total_time")          → "PT12M40S"

remaining at launch = 30m − 12m40s = 17m20s

In SCORM 1.2 the same three reads are LMSGetValue calls on cmi.student_data.max_time_allowed, cmi.student_data.time_limit_action and cmi.core.total_time. The total only grows if the content reports its session time before it closes, so a course that never writes session time will see the full allowance again on every launch.

The four time_limit_action values

The second element tells the content what the course author wants to happen at the limit. It is a fixed vocabulary of four strings, identical in SCORM 1.2 and SCORM 2004. Each one combines two choices: whether the learner leaves, and whether they are told.

The strings are exact. There is a comma with no space after it, and no message is two words. Content that compares against "exit, message" will never match.

In SCORM 2004, an LMS returns continue,no message when the manifest does not define an action, so a limit with no action is a limit with no consequence. SCORM 1.2 defines no such default, and an empty string is a common answer.

When the content does end the session because of the clock, it should say so. Both versions have an exit value for exactly this case:

SetValue("cmi.session_time", "PT17M20S")  → "true"
SetValue("cmi.exit", "time-out")          → "true"
Commit("")                                → "true"
Terminate("")                             → "true"

The SCORM 1.2 equivalent is cmi.core.exit set to time-out. Whether a timed-out attempt also counts as failed or incomplete is not something the specification decides. The content sets whatever status the course design calls for before it exits.

Where the limit is set

Both values come from the package manifest, on the item that launches the SCO. They are part of the course, not a runtime setting. The two versions write them differently, and the general layout of the file is covered in imsmanifest.xml explained.

SCORM 1.2 uses two child elements of the item:

<item identifier="item_1" identifierref="res_1">
  <title>Final assessment</title>
  <adlcp:maxtimeallowed>00:30:00</adlcp:maxtimeallowed>
  <adlcp:timelimitaction>exit,message</adlcp:timelimitaction>
</item>

SCORM 2004 keeps the action as an item element but moves the duration into the sequencing block, as a limit condition:

<item identifier="item_1" identifierref="res_1">
  <title>Final assessment</title>
  <adlcp:timeLimitAction>exit,message</adlcp:timeLimitAction>
  <imsss:sequencing>
    <imsss:limitConditions attemptAbsoluteDurationLimit="PT30M"/>
  </imsss:sequencing>
</item>

Three details cause most mistakes here:

• Case. The 1.2 element names are all lower case and the 2004 names are camel case. XML is case-sensitive, so adlcp:timelimitaction in a 2004 manifest is not the element the LMS is looking for.
• Format. 00:30:00 belongs in a 1.2 manifest and PT30M in a 2004 one. They are not interchangeable.
• Scope. The limit belongs to one item. In a package with several SCOs, each item carries its own values, and a SCO whose item has none gets none.

Because the limit lives in the manifest, changing it means editing the package and importing it again. Which version you are editing decides which of the two forms applies; the wider differences are in SCORM 1.2 vs 2004.

Who actually enforces it

The content does. The specification makes the LMS responsible for passing the two values through, and leaves the response to the SCO. Nothing in SCORM tells an LMS to close a course window when a clock runs out. In SCORM 2004 the duration sits inside the sequencing rules, which makes it look like something the LMS will police, but SCORM does not require an LMS to evaluate time-based limit conditions. For most platforms its practical role is to supply cmi.max_time_allowed.

That leaves three places where a time limit can quietly fail:

• The manifest never declared it. Many authoring tools do not write these elements at all, and run any timer entirely inside the course without telling the LMS.
• The LMS does not pass it through. Support varies between platforms, most of all for the optional SCORM 1.2 group. Some platforms also offer their own time limit in the course settings. That is a separate feature, outside SCORM, and the content cannot see it.
• The content never reads it. A course with no code that calls GetValue on the limit will ignore whatever the manifest says.

The only reliable check is a test in the LMS the course is going to. Launch the course, open the LMS's SCORM debug log or the browser console, and look for the two reads. Confirm that the limit comes back with the value from the manifest, and that the action is one of the four strings. Then let the clock run out once and watch what the course does: whether a message appears, whether the session ends, and whether the final calls include the session time and the time-out exit. Leave and relaunch partway through as well, to confirm the remaining time is shorter the second time.

If the limit matters for compliance or for a formal assessment, do not assume it holds because the manifest contains it. A learner can also close the window and reopen it, so a limit is only as firm as the content's own handling of time across sessions.

Where SCORM Central fits

SCORM Central turns PowerPoint, PDF, and video files into SCORM 1.2 or SCORM 2004 4th Edition packages you can edit in its course builder, and its free tester shows the manifest checks and every runtime call a package makes before an LMS sees it. See how it works, or test a package free.