Time management

01Why it's a feature, not a detail #sec_fe499f4b

A certification campaign is made of dated commitments: a deadline to meet, a window for contesting, a certification date that is authoritative. As soon as a client operates in several time zones — a headquarters in Paris, a subsidiary in Tokyo, a service center in the Azores — the question “what day is it?” ceases to have a single answer. Most tools ignore it: they live in the time of their server, and the client discovers one day that a deadline has fallen two hours too early, or that a report has lost its last day.

REVIEWIT treats time as a governance data in its own right. Each temporal value of the product belongs to one of two natures, and each obeys its own rules:

The instant — the precise moment when something happened: a decision made, a delegation created, an audit event. An instant is absolute; it is recorded in universal time and rendered in the reader's time.

The civil date — a day on the calendar: the deadline of a campaign, the end of a plan, a holiday, a sanctuary cycle. A civil date has no time; it only makes sense in the time zone of the one it concerns, and it stays there.

All the functionality stems from this distinction. A deadline never “slips” because a server is elsewhere; a proof timestamp never changes value depending on who reads it — only its display adapts.

02The reference time zone: the client's, at its governance level #sec_69e30f9e

Each temporal value is evaluated in a reference time zone, resolved according to a clear chain:

The workspace first. The workspace is the delegated governance scope: an entity manages its own deadlines. A Tokyo subsidiary closes its campaigns at Tokyo time, regardless of the location of the headquarters or the platform.

The subscription then. If the workspace has not declared a time zone, the subscription's applies — the setting that the client administrator defines in its parameters.

Universal time as a last resort — never the server's time, which is no one's. This fallback is logged, so that an incomplete configuration is visible to the operator rather than suffered by the user.

Changing the time zone of a workspace takes effect immediately, without interruption of service: the deadlines, countdowns and timestamps displayed follow the new setting as soon as the screens reconnect.

03What this changes, surface by surface #sec_a1ebd790

Campaigns and deadlines

The “D-3” of a campaign counts days from the workspace's calendar, not 24-hour slices from a server. A campaign planned “for the 28th” starts on the 28th at the client — not on the 27th in the evening because the platform is in the east. The “today” progress bar, the launch and closing milestones, the reminders: all speak the workspace's calendar.

The reviewer's queue, multi-site by nature

A resource owner can review for several workspaces at once — it is a principle of the product. His work queue therefore displays, side by side, requests from different scopes: each line counts its days in the time zone of its own campaign. Two neighboring requests can legitimately display two different “todays”, because it is already tomorrow in Tokyo. A delay, a near deadline, a countdown: everything is true line by line.

The certification date: one act, one date

When a request is certified, the date recorded is that of the day in the time zone of the workspace that carries the campaign — never that of the server, never that of the personal time zone of the one who clicks. Two reviewers located ten time zones apart who certify the same campaign on the same day produce the same date. This is what makes this date an opposable piece: it is reproduced as is in the certification files and proofs.

The audit trail: the exact instant, readable locally

Each audit event is recorded at the exact universal instant — it is the material of the proof, it never varies. On the screen, these instants are rendered in the time of the perimeter consulted, search bounds included: a search “from 4 to 21” covers from the beginning of 4 to the end of 21, local hours of the client. Verified in real conditions: the same event, consulted from three time zone configurations, is displayed at three exact local times — including the passage to the next day when it occurs.

Communications: published “on the 12th”, opened on the 12th at each one

A news item or a notification published by the publisher “from 12 to 20” opens at the beginning of 12 in the time zone of each subscription, and closes at the end of 20 — at each one. A client from Auckland and a client from Montreal see the same publication window, each in their calendar, without either seeing it amputated or shifted.

Plans and subscriptions: the service due until the end of the last day

An end date of a plan is a calendar commitment: the service is rendered until the end of the last day at the client, grace period included. The automatic life cycle of subscriptions (active, grace period, archiving) applies this rule — the same as the one displayed in the administration consoles, so that a client never sees his service stop before what his screen announces.

Governance cycles: sanctuary, delegations, roles

The sanctuary review deadlines, the delegation periods, the role expiration dates are civil dates of the workspace. “Added 5 days ago”, “expires in 30 days”, “review due”: all these counts are made in days of the client's calendar. A role expiration applies on the right day, everywhere, for everyone — the screen that displays it, the one that creates it and the process that suspends it read the same calendar.

Reports, charts and exports

Reports cut “over the last 30 days” cover whole civil days of the workspace — the last day included. The activity charts align their bars on these same days, so that two consultations in the day show the same slices. The exported files bear the local time of the client in their name: they are correctly classified in a download folder, and a document footer indicates a local time — or a universal time explicitly marked as such.

04The fundamental guarantees #sec_5648f06c

Storage is in universal time, display is local. Instants are kept in an absolute and unambiguous form; conversion to the reader's time is done at the time of display, never before. No “already converted” value circulates or is stored: this is what makes double conversion and cumulative shift impossible.

Civil dates do not convert. A deadline entered “on the 28th” is kept as day 28 — it never becomes “on the 27th at 10pm” somewhere. Moving a workspace from one time zone to another does not move any existing deadline.

The server's time is not involved anywhere. Neither in the deadlines, nor in the proofs, nor in the displays. The platform can be hosted in any region — and moved — without any business value changing.

The edge cases of the calendar are covered. Seasonal time changes, including time zones that switch at midnight; ambiguous autumn hours and non-existent spring hours: a date range is never amputated or overflows because of a transition.

The behavior is verified, not assumed. The complete chain — input, storage, evaluation, restitution — is covered by automatic controls, and has been validated in real application on three simultaneous time zone configurations (explicit time zone, hot switch, configuration fallback), with supporting statistical evidence.

05In summary #sec_5b091ae2

Time, in REVIEWIT, is treated with the same rigor as access rights: each value has an owner, a nature and a rule — and the infrastructure has no say.