Dates and Timezones

Shapeshift stores and displays dates in different ways depending on what the value represents.

This is important for platforms with learners, administrators or integrations operating across multiple timezones.

In general, Shapeshift distinguishes between:

A specific moment in time, such as when a Webinar starts or when a learner completes a Course.
A calendar date, where the day itself matters regardless of timezone.

Date and time values

Most scheduled activity in Shapeshift uses a full date and time.

Examples include:

Webinar start and end times
Module availability
Module due dates
Course due dates
Enrollment dates
Module start and completion times
Course completion times
Notification scheduling

These values represent a specific point in time.

Shapeshift stores these values in a consistent format and converts them for display where the learner or administrator's timezone matters.

Entering dates in the CMS

When an administrator enters a date and time in the CMS, they use the date and time shown in their own browser.

For example, an administrator selecting:

10:00 AM on 15 October

is selecting that moment based on the timezone of the device/browser they are using.

Shapeshift then stores the underlying time consistently so it can be interpreted correctly elsewhere.

This means administrators should enter scheduled times as they expect them to occur in their own local timezone unless a particular implementation has agreed different rules.

Learner timezone

Where a scheduled time is shown to a learner, Shapeshift should normally present it in the timezone relevant to that learner.

For example, a Webinar taking place at the same moment may appear as different local times to learners in London and New York.

Some client implementations may deliberately use a fixed timezone instead, particularly where external systems, regulatory requirements or reporting rules require it.

Where this applies, the behavior should be agreed as part of the implementation.

Webinars

Webinar start and end times represent real moments in time.

They should therefore be stored consistently and displayed to learners in the appropriate local timezone.

Any connected Webinar provider must use the same agreed timing rules so that the event time shown in Shapeshift matches the external platform.

Due dates

Course and module due dates are stored as DateTime values.

This allows Shapeshift to support more precise scheduling and notification behavior where required.

Even where the learner interface displays only the date, the underlying value can still represent a specific deadline.

This is important for automated reminders such as:

Due today
Overdue
Due soon

The timezone used for these calculations should match the learner or the agreed platform configuration.

Available From dates

Availability dates are also DateTime values.

This allows learning to become available at a specific point in time rather than only at the beginning of a calendar day.

The learner should see availability based on the appropriate timezone for their experience.

Completion and enrollment dates

Enrollment, module completion and Course completion are recorded as exact timestamps.

Where these are displayed to learners or administrators, they should normally reflect the appropriate local timezone.

The stored timestamp itself remains unchanged.

This allows reporting and integrations to refer to one consistent moment while presenting it correctly to users in different locations.

Certificates

Certificate dates are normally based on the learner's enrollment or completion record.

The certificate layout itself is implementation-specific, so the exact date format and timezone presentation can vary between platforms.

Where a client has regulatory or integration requirements, certificate dates may deliberately follow an agreed fixed timezone rather than the learner's local timezone.

Calendar dates

Some data represents a calendar date rather than a moment in time.

For example, a custom field such as a date of birth should remain the same calendar day regardless of where the learner is located.

These values should not be shifted simply because the user or system is in another timezone.

This distinction is particularly important for bespoke integrations and custom fields.

For example:

Webinar start: timezone-aware DateTime
Course completion: timezone-aware DateTime
Date of birth: calendar date, no timezone conversion

Notifications

Scheduled notifications can depend on the learner's timezone.

For example, a notification intended to be sent when something is due today needs to determine what “today” means for that learner.

Shapeshift therefore uses timezone information when evaluating scheduled and overdue learning.

Client-specific implementations may override this behavior where all learners are required to follow one fixed timezone.

Integrations

External systems should agree clearly with Shapeshift on whether each exchanged value represents:

A UTC timestamp
A timezone-aware DateTime
A calendar date

This avoids common issues such as dates appearing one day earlier or later after timezone conversion.

Where possible, exact times should be exchanged as UTC timestamps and converted only when displayed.

Calendar dates should remain calendar dates and should not be shifted between timezones.

Client-specific requirements

Some platforms have specific timezone requirements because of:

Regulatory reporting
Certificates
External integrations
Exam providers
Regional business rules

Where this applies, Shapeshift can use fixed timezone rules for those workflows rather than the learner's local timezone.

These exceptions should be agreed explicitly during implementation so that learner display, notifications, certificates and integrations remain consistent.