Time: The Quiet Killer

Behavioural analytics is built on time. Hour-of-day features, session reconstruction, sequence detection and rolling baselines all assume that timestamps mean what they appear to mean. They frequently do not.

The failures

No timezone in the timestamp. Extremely common in older sources. The pipeline assumes UTC, or local, or the collector's timezone. Whichever it assumes, some fraction of events land in the wrong hour.

Mixed timezones across sources. One source emits UTC, another local time, a third the collector's timezone. Events from a single session scatter across the day.

Daylight saving. Twice a year, one hour repeats and one does not exist. Sources handle this differently. Sequence analytics see events out of order; hour-of-day baselines see a discontinuity.

Clock skew. A host with a drifting clock places its events minutes or hours away from reality. Correlation with other sources fails.

Event time versus ingest time. A system using ingest time attributes a delayed event to the wrong window. Backfill after an outage assigns a day of activity to a single moment.

Precision loss. Truncation to the second, or the minute, destroys ordering within that interval — which is exactly the granularity sequence detection needs.

Why hour-of-day is the sharpest edge

"Activity outside normal working hours" is among the most-used features in the field, and among the most fragile.

Whose hours? A person in another timezone works normal hours that look nocturnal in UTC. Comparing against a global baseline flags them permanently.

Which timezone is the baseline in? If features are computed in UTC and presented in the analyst's local time, the numbers and the display disagree.

Do their hours have meaning? Someone with caring responsibilities working evenings, a person observing a different working week, a shift worker. Hour-of-day flags all of them, continuously, for reasons unrelated to risk.

The practical position: compute hour-of-day in the entity's own local time, derived from a reliable attribute rather than inferred from IP geolocation. Where local time is unknown, either omit the feature for that entity or accept and document that it will produce noise.

Windows

Every feature has a window — per hour, per day, per rolling seven days.

Boundary effects. An activity spanning midnight splits across two daily windows and looks like two moderate days instead of one large one. A determined actor can exploit this deliberately.

Alignment. Daily windows aligned to UTC midnight cut the working day in half for some regions.

Overlapping windows reduce boundary sensitivity at the cost of correlated scores, since one event contributes to several windows.

Weekends and holidays. A model without a weekday feature treats Saturday's quiet as anomalous or Monday's volume as normal, depending on how the baseline averaged them. Public holidays differ by country, and a global model without holiday awareness generates predictable noise every national holiday.

Sessions

Session reconstruction — grouping events into a coherent period of activity — depends entirely on ordering and gaps.

A gap threshold defines where one session ends and the next begins. Too short and one working period fragments; too long and a day becomes one session. Clock skew across sources makes the ordering unreliable, and events from different sources within a session may interleave incorrectly.

Where sequence matters, verify ordering on real data before trusting anything built on it.

What to do

Normalise to UTC at ingest, preserving the original timezone in a separate field.

Monitor clock skew. Compare event time to receipt time per source; a systematic offset is a skewed clock.

Store the entity's local timezone as an attribute, and compute time-of-day features in it.

Handle holidays explicitly for the countries you operate in.

Test across a DST transition before trusting sequence analytics.

A timezone audit

Worth running once, before any temporal feature is trusted.

For each source, determine what the timestamp actually represents. Event time, collection time or write time. Ask the vendor and then verify against a known event.

Determine the timezone and whether it is explicit. Sources emitting local time without an offset are the dangerous case.

Compare a known action across sources. Perform an authentication, then find it in every source that should have recorded it. The timestamps should agree within seconds. Where they do not, you have found either skew or a timezone assumption.

Check behaviour across a daylight saving transition using historical data. Look for duplicated or missing hours.

Establish where each entity's local time comes from. An attribute is reliable; geolocation of an IP address is not, particularly for VPN users.

An afternoon of this prevents a category of unexplained output that otherwise persists for years.

Common false positives

Time handling produces recurring, explicable noise:

Distributed teams flagged for working hours that are normal where they are.

Overnight batch jobs crossing a window boundary and appearing as two partial days.

Travel, where a person's working hours shift legitimately for a fortnight.

Daylight saving transitions, producing a synchronised anomaly for everyone twice a year.

Systems in a fixed timezone — often UTC — used by people who are not, so every event appears displaced.

On-call rotations, where night activity is scheduled and entirely expected.

Blind spots and assumptions

That the timestamp is the event time. Sometimes it is the write time, the collection time, or the time a batch was assembled.

That ordering is reliable. Across sources it usually is not.

That the timezone attribute is correct. It is HR data, and HR data ages.

That unusual hours mean anything. For a distributed workforce, hour-of-day is among the weakest features available and among the most likely to produce discriminatory output.