Purpose of time zone settings

Many Finger Manager records contain time information, including user registration time, order creation time, execution time, deposit and withdrawal time, notification send time, KYC / KYB status update time, login time, operation log time, system event time, and report statistics time.

After the system time zone is configured, related pages can display time according to the current Organization time zone.

Default time zone

Institutions can select a default time zone in system settings.

Common examples include Asia/Tokyo, Asia/Hong_Kong, Asia/Singapore, Europe/London, America/New_York, and UTC.

It is recommended to use standard IANA Time Zone names to avoid problems caused by daylight saving time and regional time rules.

Time zone and system display

For example, if the Organization time zone is set to Asia/Tokyo, time in the back office is displayed in Japan Standard Time first.

Order creation time 2026-08-28 14:00 UTC can be displayed as 2026-08-28 23:00 JST in the Tokyo time zone.

The system performs the time conversion according to the configured time zone.

Impact on reports

Time zone settings may also affect date boundaries in statistics and reports.

For daily reports, such as daily order count, daily execution amount, daily login count, or daily notification count, the definition of a day usually follows the configured Organization time zone.

If the institution uses Tokyo time, the daily statistics window usually runs from 00:00 to 23:59 Tokyo time.

For cross-region operations, institutions should confirm the unified reporting time zone before launch.

Global business scenarios

Institutions operating in multiple countries or regions can choose a time zone based on internal management practice.

Common strategies include using headquarters time, the primary market time, UTC, or a specified operations-center time.

For example, a global financial institution may use UTC to reduce time differences between regions, while a Japan-local institution may use Asia/Tokyo as the default system time zone.

Trading market time

System time zone and trading-market time are not always the same.

Markets such as US stocks, Hong Kong securities, Japan securities, foreign exchange, and digital assets may each use different local or exchange time rules.

Finger Manager can display related time according to the Organization system time zone, but actual trading sessions, market open and close times, and product trading rules should follow the corresponding market or data-source time rules.

External system time

When Finger Manager exchanges data with other systems through API, FIX, webhook, or other methods, time fields may use UTC, Unix Timestamp, ISO 8601, source-system local time, or another explicit format.

During system integration, institutions should confirm the time format and time zone definition for each interface.

At the interface layer, UTC or ISO 8601 values with clear time zone information are recommended where possible.

Daylight saving time

Some countries and regions use Daylight Saving Time, such as America/New_York and Europe/London.

In these time zones, the system should follow standard time-zone rules to handle daylight-saving transitions.

It is not recommended to replace regional time zones with fixed offsets such as UTC+8 or UTC-5, because fixed offsets can cause time differences during daylight-saving changes.

Using standard regional time zones can reduce errors caused by daylight-saving transitions.

Recommendations

Before launch, institutions should confirm a unified default time zone.

Report statistics should remain consistent with the system time zone.

Cross-border operations may prefer UTC, while local operations can use the main operating-region time zone.

API and system integrations should define time formats clearly.

For trading time, institutions should follow the rules of the corresponding market.

Notes

Time zone settings mainly affect the display of date and time information in Finger Manager and some statistical definitions.

Different modules, external systems, trading markets, and third-party data sources may use different time standards.

When performing system integration, report reconciliation, or cross-region business processing, institutions should also confirm the time-zone definition of each specific data field.