A recent Canadian Bibliographic Committee meeting featured a discussion about the implementation of dates in product metadata including the current Date Recommendations for Canadian Publishers. In the conversation about dates, a question came to BookNet about ONIX’s ability to support “product drops” in a time-sensitive manner. Drops, in retail speak, refers to when a new product hits the sales floor. It has come into modern parlance in social media retail sales when a new product or product line is hyped online and web ordering goes live at a specific date and time. We thought we’d check in with EDItEUR’s data definer extraordinaire Graham Bell, to see how ONIX supports time-specific releases for books.
As Graham explains, times, in terms of pub dates and sales embargoes, are fully supported in ONIX. Here’s a modified version of the section in the ONIX Implementation and Best Practice Guide on dates with times. I’d say that relatively few authors and books merit a timed release, though you’ll remember readers lining up at midnight for the latest Rebecca Yarros release — appropriately named Onyx Storm — only a couple of days ago.
Most dates are just that — dates. But increasingly, particularly for digital publications, embargo dates are set to specific times to support a ‘product drop’ or retail launch event. Some date formats available in List 55 allow a time to be included for publication dates, sales embargoes (a.k.a. strict on sale dates), and for other dates like an embargo on orders (when pre-orders can go live). These dates can specify either a rolling local time or a specific instant in time. As an illustration of the difference, consider the meaning of these three sales embargo dates:
<Date dateformat="13">20250812T1500</Date>
<Date dateformat="13">20250812T1500-0400</Date>
<Date dateformat="13">20250812T1900Z</Date>
The first has no timezone information, and is therefore a ‘rolling time’, meaning that retail sales are embargoed until 3 p.m. local time — thus the product goes on sale in Toronto at 3 p.m. — but sales can begin some five hours earlier in London (i.e., at 3 p.m. in London), and cannot begin for a further three hours in Vancouver (i.e., at 3 p.m. local time in Vancouver).
The second and third examples specify a particular instant in time — 3 p.m. in a time zone four hours behind UTC, or 7 p.m. UTC. This means that the product can be sold beginning at 3 p.m. in Toronto (because in August, Toronto is four hours behind UTC on that particular date), and sales can begin in London and Vancouver at exactly the same instant (i.e., at 8 p.m. in London, because in August, London is one hour ahead of UTC, and at noon in Vancouver, because Vancouver is seven hours behind UTC).
It's critical that publishers setting embargoes with exact time parameters decide whether the embargo time is rolling or instantaneous, and that they use the correct format to specify the time. Note that it may not be possible for ebook or online retailers selling to customers in many countries (or even within a single country that stretches across several time zones) to apply rolling time embargoes properly because of limitations in their internal and customer-facing systems.
Times that include timezone information (i.e., instants in time) should wherever possible express that time in UTC.
Midnight embargoes can be specified with a time of either 24:00 or 00:00 — the former logically indicates an embargo that expires at the end of a day, and the latter indicates expiry at the beginning of the following day — and these are of course exactly the same time. The following two examples appear to indicate an identical rolling embargo time — but of the two, the second is very strongly preferred:
<Date dateformat="13">20250811T2400</Date> (end of August 11)
<Date dateformat="13">20250812T0000</Date> (beginning of August 12)
The reason for this is that if some data recipient cannot support times, with the second option they will at least begin selling the product on the correct day (albeit about nine hours late … ) but not a day early.
ONIX dates are inclusive, and in general, it's natural to use 00:00 for midnight datetimes that express start dates (e.g., a Valid from … date in an ONIX <Date> element), and 24:00 for midnight datetimes that express end dates (e.g., a Valid to … date). That is, something starts at the beginning of the day on the specified date, and ends at the end of the day on the specified date. The recommendation for sales embargoes might appear to contradict this, but it's important to understand that the date represents the earliest date on which sales are allowed, not the last day on which sales are embargoed, so it's a start date. It’s therefore natural to use 00:00 to indicate midnight at the beginning of the day on which sales are allowed. The same is true of other embargo dates in ONIX <Date> elements.
When the date is an end or Valid to … date, either 24:00 or 00:00 are acceptable options, though 00:00 is clearly less natural than 24:00 — it’s ‘00:00 on the day after’ rather than midnight at the end of the day — so using 24:00 is recommended in these cases.
Note however that use of a time of 24:00 to indicate midnight at the end of a day has the potential to cause problems in some recipient systems where dates and times are handled programmatically. Digital clocks tick over from 11:59 to 00:00, not to 24:00, and some systems do not treat 24:00 as a valid time. For data senders, if 24:00 is impractical and 00:00 on the day after seems unclear (i.e., 20250811T2400 or 20250812T0000 for a price that is valid to the end of August 11), use a time of 23:59 (or even 23:59:59) instead. For data recipients, 24:00 may need to be treated as a special case, and equated to 00:00 of the following day.
Dates without times of any kind can be thought of as a special kind of rolling time, aligned with the business day, essentially meaning ‘the start of the business day’ (or for ‘to’ dates, the end of the business day). So a date of 20250812 perhaps means 9 a.m. on that day for a physical bookstore, but 00:00 at the beginning of that day for an online bookstore that operates 24×7. Of course for an online store, the question is, 'Midnight where?’ It’s for this reason that, as noted above, a rolling time can present special difficulties online. However, since online stores use geolocation techniques so the correct sales rights, prices, taxes and currencies can be used with each customer, they should be able to use the customer’s local timezone too.
And there you have it: publishers can support retail drop culture through their ONIX communication with their retail and distribution partners. Now, you know what to do…
BookNet Canada runs the Canadian Bibliographic Committee and sits on the international ONIX Committee that makes decisions about how to improve and expand ONIX standards to keep up with the needs of the industry. We've built quality reports into BiblioShare for quick and easy feedback, we’ve developed many resources to help you navigate ONIX, and are on-hand to troubleshoot things with you. If you would like to discuss changes to ONIX, or are interested in participating in the Canadian Bibliographic Committee, please send us a message at standards@booknetcanada.ca.
Want to make data-informed decisions? We can help.