# Get network date and time

`GET /api/configuration/system/time/current-time`

- **Success:** `200 OK`
- **Products:** Operator (`FOH`), Consumer (`CONSUMER`) (any one of these products, not all)
- **Features:** Online Bookings (`ONLINEBOOK`), Online Joining (`ONLINEJOIN`), Front of House Generic Access (`FOHGENERIC`) (any one of these features, not all)

HTML version: [Get network date and time](https://support.gladstonesoftware.cloud/reference/configuration/get-network-date-and-time)

## Overview

Returns the current time, read from public NTP time servers and converted into whichever time zone
you name.

**Be clear about what clock this is.** It is not a Gladstone business clock, not a site's trading
date, and not a value stored anywhere in the platform. On each request the platform queries a
public NTP server over UDP — `time.google.com`, then `time.windows.com`, then `pool.ntp.org`,
stopping at the first that answers — reads the transmit timestamp from the reply, and converts it
to the requested zone. Nothing is cached and nothing comes from your tenant's data. Two calls a second
apart produce two separate NTP round trips.

The reason to use it rather than your own clock is narrow but real: it gives you a reference time
that is independent of both your machine and the Gladstone server, in the same time zone the
operator works in. If your integration decides whether a booking cut-off has passed, or which
trading day a transaction falls on, a device with a drifting or misconfigured clock will make that
decision wrong, and reconciling afterwards is painful. Reading this endpoint at the start of a
session and holding the offset against your own monotonic clock is the sensible pattern.

Do not call it per operation. It is a network round trip to a third-party server on every request,
it is the endpoint in this service most prone to timing out, and if UDP port 123 is blocked between
the Gladstone cluster and the internet every call fails with `500` until that is fixed.

## Endpoint

`GET {base_url}/api/configuration/system/time/current-time`

`{base_url}` is the environment URL issued to your integration. See [Authenticating with Gladstone APIs](../../guides/authenticating-with-gladstone-apis.md).

## Query parameters

| Name | Type | Required | Description |
|------|------|----------|-------------|
| `timeZoneId` | string | No | The zone the returned time is expressed in. **Omit it and you get `Europe/London`** — the default is applied server-side, so a UK integration can leave it off entirely, and an integration outside the UK that forgets it will silently receive British time rather than an error. The value is resolved by the .NET runtime's time zone lookup and the built-in default is an IANA identifier such as `Europe/London` or `America/New_York`. Anything the host cannot resolve returns `404`, not a fallback to the default. |

## Sample request

```bash title="cURL"
curl -X GET '{base_url}/api/configuration/system/time/current-time?timeZoneId=Europe/London' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Response fields

| Field | Type | Description |
|-------|------|-------------|
| `dateTime` | string (date-time) | The current time **already converted into `timeZone`** — a local wall-clock reading, not UTC. It is serialised with no `Z` and no `+01:00` offset, so a parser that defaults unqualified timestamps to UTC will be an hour out during British Summer Time and silently correct in winter, which is the worst kind of bug. Combine it with `timeZone` yourself, or convert back to UTC before storing. Precision comes from the NTP reply and includes milliseconds; treat it as accurate to well under a second, but not as a monotonic source — call it once and track elapsed time locally. |
| `timeZone` | string | The zone `dateTime` is expressed in, echoed back exactly as it was resolved. When you omitted `timeZoneId` this is how you discover the default that was applied, so read it rather than assuming. It is the identifier only — no offset and no abbreviation — so it does not on its own tell you whether daylight saving was in effect. |

## Sample response

```json title="200 OK"
{
  "dateTime": "2026-08-14T19:00:00.123",
  "timeZone": "Europe/London"
}
```

## Errors

| Status | Meaning | When |
|--------|---------|------|
| `404` | Not found | `timeZoneId` is not a zone the server can resolve. The body is a plain-text string: `The specified time zone '{timeZoneId}' is invalid.` Note the status: an unrecognised zone is reported as `404`, not `400`, so do not treat `404` on this endpoint as "endpoint missing". |
| `500` | Internal server error | Every configured NTP server failed to answer — commonly a firewall blocking outbound UDP on port 123, or the NTP server list being absent from the platform's configuration. The body is empty. This is a transient infrastructure failure rather than a fault in your request, so retrying is reasonable, but if it persists there is nothing a caller can change to fix it. |