Date shifting in de-identification: when it helps and when it breaks timelines

When should dates in business records be shifted?#

Dates in business records should be shifted only when they identify a person, alone or combined with other fields. A ticket opened on a Tuesday or an invoice paid at month end says nothing about who was involved, and shifting it destroys useful signal for no privacy gain.

Dates become identifying in a few predictable ways. Personal life dates such as birth, hire, termination and leave dates point to one employee or candidate. Visit dates tied to a household, such as a residential service call, can single out a family when combined with a neighborhood. Any date that coincides with a rare public event, such as a named storm, a product recall or a lawsuit filing, can connect an otherwise anonymous record to a known party.

For reference, the HIPAA Safe Harbor method, written for health data, removes all elements of dates except the year for dates directly related to an individual. Most operational datasets do not need to go that far, but the rule is a reminder that personal dates deserve the most attention.

How per-entity date shifting works#

Per-entity date shifting assigns each entity, such as a customer account, an employee or a service location, its own random offset and applies that offset to every date belonging to that entity. Because all of that entity's dates move together, the gap between a ticket's creation and its resolution, or between an estimate and the job it won, stays exactly the same.

Managed tools can do the arithmetic. Google's Sensitive Data Protection API, for example, includes a date-shifting transform that moves dates by a random number of days within a range you configure. The harder work is choosing the entity key and making sure every date, structured or not, passes through the same offset.

• 1Choose the entity key: the person, account or location whose timeline must stay internally consistent.
• 2Generate one random offset per entity and store it in a key table inside the preparation environment.
• 3Apply the offset to every structured date field linked to that entity, including created, updated and closed timestamps.
• 4Find and shift dates written in free text, subject lines, file names and attachment metadata.
• 5Validate by recomputing intervals before and after shifting; they should match exactly.
• 6Record which fields were shifted, by entity type, in the dataset documentation.

Where date shifting breaks timelines#

Date shifting breaks any analysis that depends on the real calendar or on comparing entities with each other. Once two customers are shifted by different offsets, an outage that hit both on the same afternoon appears as two unrelated events far apart.

Operators feel this most. An HVAC contractor's call volume follows heat waves and cold snaps, and a distributor's exceptions spike around holidays and quarter-end. Shift those records by random offsets and the seasonal pattern dissolves. Software companies hit the same wall when a release fixes bugs reported by many customers: with per-customer offsets, the fix can appear to ship before the reports that prompted it.

Global offset, per-entity offset or generalization?#

The choice between a global offset, per-entity offsets and generalization depends on which relationships the dataset must preserve and how exposed the real dates are. A global offset moves everything by the same amount, so cross-entity comparisons survive, but one recognizable public event is enough to reveal it.

Generalization trades precision for safety and leaves no key to protect. Reducing dates to month, quarter or year keeps seasonality and long-run trends. Relative time, where each entity's first event becomes day zero, keeps durations and order without any calendar at all, which suits workflow studies such as escalation paths or quote-to-order cycles.

Dates hiding in free text#

Dates hiding in free text are the most common reason date shifting fails. A structured created-at field gets shifted, but the email body still mentions the March board meeting, and anyone who sees both values can compute the offset and reverse every other date for that entity.

Search every text field before release, in the formats people actually write: full dates, month and day without a year, holiday references, quarter labels and phrases such as since we opened. Quoted email replies are a frequent miss, because each quoted message carries its own original sent line. Ticket numbers, invoice numbers and file names sometimes embed a date as well.

Relative expressions, such as yesterday or by end of week, can usually stay, because they carry no anchor. The test is simple: could a reader combine this text with a shifted field to recover the real date? If yes, shift or generalize the text too.

Illustrative: a residential HVAC contractor's service history#

Illustrative: a fictional HVAC and plumbing contractor with several years of ServiceTitan history wants to license its service records: calls, estimates, jobs, technician notes, invoices and callbacks. Most customers are households, so a visit date combined with a neighborhood could point to a family.

The team first tried per-customer offsets. The buyer's questions centered on seasonal load and callback rates after summer installs, and the shifted data scattered every heat wave across the year. The team changed approach: exact dates became year and month plus weekday, addresses were reduced to a broad region, and each location's timeline was expressed as days since its first service call.

The result kept what mattered. Callback intervals, estimate-to-job conversion times and seasonal peaks survived, while no record carried an exact visit date for a household. The method, the fields affected and the reasons went into the dataset card so the buyer would not mistake generalized dates for errors.

How SourceX handles dates during preparation#

SourceX treats dates as a field-by-field decision in the Preparation step of the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Each date field is classified as keep, shift, generalize or remove, based on whether it identifies someone and what the licensed use requires.

The chosen method is recorded in the privacy record of the SourceX Evidence Packet, alongside provenance, licensing rights, permitted use and release authorization. Offset tables stay with the supplier or the preparer inside the staging environment, and the supplier approves the treatment before anything is released.