In this article
A reliable availability calendar separates workload time from preparation and records exceptions in an unambiguous time zone.
A GPU availability calendar should record named time zones, specific UTC timestamps, owner reservations and the time needed to return the machine to its next task. A recurring phrase such as evenings available is insufficient for coordinating work across countries.
The calendar describes a resource offered for discussion. It does not establish customer demand or guarantee that every listed hour will be used.
Keep local recurrence and UTC events
For recurring availability, name the calendar zone rather than writing our time. Python’s zoneinfo documentation explains named IANA time zones and their rules. A fixed offset should not be assumed to describe every date in every location.
For a specific event, preserve its UTC representation as well. For example, 20:00 at an explicitly supplied offset of +04:00 corresponds to 16:00 UTC. This is an offset conversion example, not a universal rule for a particular city.
Separate workload time from handover
A server may stop accepting outside work before it becomes ready for its owner. Environment loading, result transfer and verification can occupy a separate interval. Measure those actions rather than using an arbitrary buffer as proof of readiness.
| Calendar item | What it means | Who confirms it |
|---|---|---|
| Offered interval | External work may be considered | Equipment owner |
| Intake cutoff | No new tasks accepted | Workload operator |
| Preparation | Resource returned to required state | Administrator |
| Research reservation | External work is excluded | Research owner |
| Maintenance exception | Normal schedule changes | Authorised contact |
For marketplace use, check the platform’s own procedures. Vast.ai’s maintenance scheduling is a separate mechanism, not an automatic interpretation of a personal calendar entry.
Keep exceptions as a versioned list
Record holidays, site work, network interruptions and changes to research dates. Each exception needs a date, reason, approving person and revised readiness expectation. Preserve the previous version so participants can explain which schedule applied to an earlier decision.
Also define what happens if the owner unexpectedly needs the GPU sooner. A request to change the calendar does not itself resolve active workload commitments. The discussion path should be clear before external work begins.
Test a complete transition
Run one bounded cycle from owner use to the proposed external task and back. Observe when access changes, files are transferred and the receiving user verifies the environment. Record delays as evidence for the next version of the calendar.
Include known exceptions and preparation needs. A realistic schedule with explicit gaps is more actionable than an unsupported promise of uninterrupted availability.
Continue with Vast.ai Offer End Date: Plan When Your Server Must Return and Return a GPU to Its Research Window.