Field Ops

Australia doesn't use a single timezone. Sydney runs AEST (UTC+10) or AEDT (UTC+11 during daylight saving). Perth is AWST (UTC+8) with no saving. Adelaide is ACST (UTC+9.5), yes really, thirty minutes. If your Velocity X instance spans multiple states—crews in Perth, dispatch admin in Sydney, jobs in Brisbane—a naive timezone implementation will destroy your booking logic. You'll have reps showing up an hour before jobs start. Dispatch will see "4pm booking" and assume it's their time, not knowing it's a Perth local. Velocity X solves this: every timestamp is stored in UTC, then rendered in each user's preferred local timezone at display time. One source of truth, infinite regional views.

Here's how the pattern works and why it matters for multi-state field ops.

Why Single-Timezone Booking Breaks Multi-Region Teams

Imagine a Perth crew gets a job scheduled for 3pm. Dispatch in Sydney enters "3pm" into the system, meaning 3pm Sydney time (AEST). The crew gets an alert: "Job at 3pm." But they're in Perth, where it's actually 1pm—30 minutes earlier. They either show up 2 hours early or they're 2 hours late depending on how they interpret the alert. Worse: if Sydney just switched to daylight saving (AEDT, UTC+11) but Perth didn't, the offset is now 3 hours. One timezone assumption breaks the entire operation across state lines.

The root problem: most scheduling systems store time in "local" format—just a string like "3pm"—without tracking *which* timezone that 3pm belongs to. When different users pull that record from different regions, they each assume it's their own local time. Velocity X flips this. Every timestamp is stored as a Unix timestamp (seconds since epoch, January 1, 1970 UTC) or an ISO-8601 string in UTC (e.g., `2026-06-13T05:00:00Z`). When a Sydney admin views the job, the client shows "3pm AEST." When the Perth crew views it, the client shows "1pm AWST." Same job. Correct time everywhere.

The UTC-Storage, Local-Display Pattern

Here's the pattern in three steps: (1) When a user creates a booking, the system captures their current timezone from their profile (e.g., "Australia/Sydney"). The user enters a time in their local UI—"3pm tomorrow." The client calculates the UTC equivalent by converting their local time + offset into UTC. That UTC value is stored in the database. (2) When the same booking is fetched by any user—whether they're in Sydney, Perth, or Brisbane—the server returns the UTC timestamp. (3) The client reads the user's timezone preference from their profile and converts UTC to local time for display. The UI renders "3pm AEST" for Sydney, "1pm AWST" for Perth, automatically.

This pattern uses a library like `date-fns-tz` for JavaScript or `pytz` for Python. Here's the money code: a repo in Sydney books a job for 2026-06-13 at 3pm AEST. The client runs: `zonedTimeToUtc('2026-06-13 15:00:00', 'Australia/Sydney')` → returns UTC timestamp `1718248800` (or `2026-06-13T05:00:00Z`). That's stored in the database. A Perth crew member fetches the same job. The client runs: `utcToZonedTime(1718248800, 'Australia/Perth')` → renders `2026-06-13 13:00:00` on their screen. No API changes. No manual offset math. One function per direction.

User Timezone Profiles and Defaults

Every user in Velocity X has a timezone setting in their profile. When they log in, the system detects their browser timezone (JavaScript's `Intl.DateTimeFormat().resolvedOptions().timeZone`) and pre-fills it, but they can override it. A Sydney-based dispatcher can set their preference to "Australia/Melbourne" if they prefer. A Perth crew member can manually select their timezone on first login. Roles matter: admin/dispatch profiles set the "default" timezone for ambiguous bookings. If a job is created by an automated process without a user context, the job defaults to the dispatch admin's timezone, then surfaces with a tooltip: "Created in Sydney time—verify for your region."

Daylight saving transitions are handled by the timezone library, not manual logic. On the day Sydney switches from AEST to AEDT (first Sunday in October), the library automatically adjusts the offset from +10 to +11. Perth and Brisbane don't change. The system keeps running; no code updates needed. Job times don't jump or vanish during the transition because they're always stored in UTC, which doesn't observe daylight saving.

Six Questions Your Multi-Region Team Will Ask

What if a crew member travels between timezones mid-week?

They update their timezone preference in settings. All future bookings render in their new local time. Past bookings still display correctly because UTC + their old timezone setting still makes sense—the app doesn't rewrite history. If they move from Sydney to Perth mid-week, jobs scheduled for Thursday will show Perth time; jobs completed last Monday still show the Sydney time they were in when completed.

Can I book a job from Sydney and assign it to a Perth crew instantly?

Yes. When you click "assign to crew," the job's UTC timestamp doesn't change. The assigned crew member's timezone preference is fetched. If they're set to Perth time, they see the booking in their local time. If they're set to Sydney time (perhaps they visit Sydney often), they see it in Sydney time. No conversion errors.

What about daylight saving transitions—do jobs shift?

No. Jobs stored in UTC never shift. Daylight saving affects *display only*, not the underlying timestamp. If a job is stored as `2026-10-04T07:00:00Z` (UTC), it will display as "5pm AEDT" for Sydney users after the transition and "3pm AWST" for Perth users (no change, since Perth doesn't observe saving). The same UTC value is constant across the transition.

How do I handle timezones in reports or exports?

The export includes both UTC and the user's local timezone. A CSV export to a Sydney admin shows "2026-06-13 3pm AEST" as the human-readable column and `2026-06-13T05:00:00Z` as the ISO column. A Perth manager opening the same export sees "2026-06-13 1pm AWST" in the local column, same ISO UTC underneath. Third-party tools can choose which column to use.

What if I bulk-edit jobs from different timezones?

Bulk-edit applies relative to the dispatcher's current timezone. If Sydney dispatch moves 10 jobs forward by 2 hours, those jobs are moved 2 hours forward in Sydney time, which is the same 2 hours for Perth (both zones shift together). If you're editing cross-timezone, the UI warns you: "You're in Sydney time. These jobs are for Perth crew. Show times in Perth?" and offers a toggle.

Can API integrations ignore timezones and just use UTC?

Strongly recommended. The API returns all timestamps in ISO-8601 UTC (`2026-06-13T05:00:00Z`). Client applications can convert to their required timezone using the same pattern. Dispatch integrations, CRM syncs, and external calendars all work with UTC internally; they display local time to their users without special handling.

The Bottom Line

Multi-region field ops demands timezone handling you can trust. UTC storage means your data is zone-agnostic. Local display means every team member sees the right time for their region. No surprises. No missed jobs. No crew showing up early because Sydney decided to switch to daylight saving and Perth didn't. See how Velocity X layers time-blocking on top of timezone correctness at calendar time-blocking for field reps, or check pricing for teams spanning Perth, Adelaide, Brisbane, and Sydney.