A word of caution to PHP developers and others about xAPI timestamps.
My involvement in xAPI or Experience API specification has led me to explore a number of finer technical details that I never imagined existed. The specification is pedantically precise in places, and it needs to be. For all of the learning industry’s software to work seamlessly and smoothly for the end user, the programs in the background need to be exact in their communication; nobody wants to lose the tracking data of thousands of learners on the launch of a new training course because somebody missed a colon.
The format of the timestamp string is one of these pedantic technical details that needs to be right. There’s a specific set of standards outlined by the ISO organization (ISO 8601) that describes the format of this timestamp, and the xAPI specification simply references that existing standard. Using an existing standard makes things simpler, because:
- ISO have already done the hard work of defining the standard.
- Many programming languages have built-in functions to generate compliant timestamps.
Programming languages are created by some very clever people, so you can expect to rely on them to get the standard right. Can’t you?
Well actually, no. PHP’s function to create an ISO 8601 timestamp in fact generates one that doesn’t quite follow ISO 8601 exactly. This isn’t so much of a problem if you’re only ever interacting with PHP platforms as PHP can interpret it’s own timestamps, but as soon as you want to use that data with other software, for example with a xAPI powered tool or system, you risk running into problems. One developer on the PHP forums outlines an issue with attempting to read the PHP generated timestamps in an iPhone JavaScript application, for example.
Discovery of this bug is particularly timely, as with the recent release of a number of LRS conformance tests, we can expect LRSs to become stricter on what data they’ll accept. The LRS in SCORM Cloud, for example, will reject any statements with an incorrectly formatted timestamp.
The good news is that PHP includes an alternative function to generate an ISO 8601 formatted string and this returns a valid timestamp. This means that fixing your PHP application may be as simple as changing one line of code. PHP developers can find an example of this alternative function here.
We should also mention that our TinCanPHP library was also affected by this issue (like you, we didn’t expect a bug in PHP itself). We’ve corrected it now so if you’re using TinCanPHP we recommend you update as soon as you can. If you’re not using TinCanPHP or one of our other libraries, tricky technical details like this are one reason why you should!
Got questions? Get in touch.
