A time zone common time processing method and system

Abstract

The application discloses a time zone common time processing method and system; belongs to computer time data processing technical field, the method obtains the system time service time corresponding to the event to be processed and the terminal or the time zone of the event place, reads the pre-configured common time reference time zone, and carries out time zone conversion to generate a common time field, a local time field, a time zone offset field and a date offset field; the above-mentioned fields are written into the event time record; in response to the event display, sorting or time consistency check request, a unified time axis is established according to the common time field, the common time field is taken as a unified time display item, and the localized display result, the sorting result or the check result is output in combination with the local time field, the time zone offset field and the date offset field; thereby, the time reference confusion of cross-time zone events, the cross-day misjudgment and the inconsistent risk of sorting and checking are reduced.

Description

Technical Field

[0001] This application belongs to the field of computer time data processing technology, specifically a time zone common time processing method and system. Background Technology

[0002] With the development of international communications, cross-border business, air and shipping, remote conferencing, online transactions, and global collaborative work, the same event often needs to be understood and executed by users in different time zones. Current time processing methods typically use the local time of the event creator or the event's location as the basis for recording and displaying the time; that is, each region displays the corresponding time according to its time zone. For example, Beijing, Tokyo, London, and New York have different local clocks at the same moment. When users read meeting times, flight times, contract fulfillment times, or system task execution times, they need to determine whether the time belongs to the creator's location, the recipient's location, the event's location, or the server's processing time.

[0003] In cross-time zone event handling, existing systems typically write the user-input time, terminal system time, or server-received time as a single time field into the event log, and continue to read this field during subsequent display, list sorting, log retrieval, or time verification. Because this single time field does not stably distinguish between a unified processing benchmark and the local display benchmark, subsequent processing modules may interpret it according to different time zone rules, leading to inconsistent time meanings for the same event across different terminals, different business modules, or different verification processes.

[0004] Especially when an event involves multiple regions, if the system only writes a single time value such as "October 8, 2018, 9:50", users in different regions may interpret the time according to their local time; the sorting module may also directly compare local times from different sources. For events that cross date boundaries, if only the time is converted without specifying the relative date relationship, it is easy to encounter the problem of local dates being one day ahead or one day behind not being recognized, thus causing misunderstandings in the localized display of events, misalignment in unified sorting, and inconsistent time consistency verification.

[0005] While appending text such as "Beijing Time," "Tokyo Time," "London Time," or "New York Time" to the time can assist human reading to some extent, this text description usually exists as displayed text and is difficult for sorting, validation, or log processing modules to read and reuse reliably. In a large number of schedules, system logs, task queues, and message records, relying solely on manual text descriptions can also lead to problems such as inconsistent formatting, difficulties in field parsing, and inconsistent validation criteria.

[0006] Therefore, a common time zone processing method is needed to enable computer systems to consistently read the time basis used for unified sorting and time consistency verification, the time basis used for location display, and the cross-day relationship between the two at the event record level, so as to reduce the problems of misunderstanding in cross-time zone event display, sorting misalignment, and difficulty in time consistency verification. Summary of the Invention

[0007] This application provides a time zone common time processing method and system to solve the problems that easily arise when cross-time zone events are recorded and displayed using only local time, such as time base confusion, incorrect judgment of cross-day dates, difficulty in unified sorting, and inconsistent trigger verification.

[0008] In a first aspect, this application provides a common time zone processing method, which can be applied to a terminal or a server. The method includes: obtaining the system time synchronization time corresponding to an event to be processed, and obtaining the local time zone of the terminal or the location corresponding to the event to be processed; reading a pre-configured common time reference time zone, wherein the common time reference time zone is a time zone selected from multiple candidate time zones, used to uniformly map the local time of events to be processed corresponding to different local time zones to a common time field under the common time reference time zone, and serving as the time reference for the unified display, sorting, and verification of the events to be processed; performing time zone conversion based on the system time synchronization time, the local time zone, and the common time reference time zone to generate a common time field, a local time field, a time zone offset field, and a date offset field for the event to be processed. The date offset field is used to characterize the offset relationship between the date corresponding to the local time field and the date corresponding to the common time field; the common time field, the local time field, the time zone offset field, and the date offset field are written into the event time record of the event to be processed; in response to an event display request, event sorting request, or time consistency verification request for the event to be processed, the event time record is read, and when the request is an event display request, the same common time field is output to multiple terminals corresponding to different local time zones, and the common time field is used as a unified time display item; a unified timeline is established based on the common time field, and localized display results, sorting results, or verification results are output based on the local time field, the time zone offset field, and the date offset field.

[0009] Using the above method, when processing cross-timezone events such as meeting events, flight events, transaction events, contract fulfillment events, or task triggering events, the terminal or server no longer stores only a single local time. Instead, it synchronously generates a common time field for unified backend processing and a local time field for users in the same location to understand. The conversion relationship between the two is clearly defined through timezone offset and date offset fields. Therefore, events can be sorted, triggered, and validated according to the same common time base, and can also be displayed locally according to the user's location, thereby reducing the risk of users in different time zones having different understandings of the same event time.

[0010] In one possible implementation, the system time synchronization can be a unified timestamp or a local date and time. When the system time synchronization is a unified timestamp, it is used as the time zone conversion input; when the system time synchronization is a local date and time, it is parsed into a unified timestamp by combining the local date and time with the source time zone. When multiple time synchronization sources exist, the time synchronization source can be selected according to the priority of the business server time synchronization interface, network time synchronization service, and operating system clock, and the time synchronization source identifier can be recorded in the event time record.

[0011] In one possible implementation, the location time zone can be obtained from at least one of the event-specified time zone, user account time zone, event location time zone, and terminal system time zone. When the time zones corresponding to multiple time zone sources are inconsistent, the location time zone can be determined according to the priority of the event-specified time zone, user account time zone, event location time zone, and terminal system time zone, and the corresponding time zone source identifier can be written into the event time record. This can reduce inconsistencies in display results caused by different system components using different location time zones.

[0012] In one possible implementation, the common time base time zone can be read from a common time base configuration table. The terminal or server reads the common time base time zone corresponding to the event to be processed from the common time base configuration table; wherein, the common time base configuration table is generated during system initialization, service type creation, or when a service organization activates cross-time zone event processing functionality; the configuration rows in the common time base configuration table include service type, candidate reference time zone, reference time zone offset, time zone rule version, effective time range, and configuration status; the terminal or server selects a configuration row from the common time base configuration table whose configuration status is enabled and is within the effective time range, based on the service type corresponding to the event to be processed, and determines the candidate reference time zone in the configuration row as the common time base time zone.

[0013] In one possible implementation, a time zone rule base can be read before time zone conversion. The terminal or server converts the system time synchronization time into a unified timestamp and reads the time zone rule base; wherein, the time zone rule base includes a time zone identifier, rule version, effective date range, and time zone offset; the terminal or server, based on the local time zone, the common time reference time zone, and the date corresponding to the system time synchronization time, reads the time zone offset corresponding to the local time zone and the time zone offset corresponding to the common time reference time zone from the time zone rule base, respectively, and uses the time zone offset corresponding to the local time zone as the local time zone offset and the time zone offset corresponding to the common time reference time zone as the reference time zone offset; the local time zone offset and the reference time zone offset are used to generate the common time field, the local time field, and the time zone offset field.

[0014] In one possible implementation, the time zone conversion includes: converting the system time synchronization time into a coordinated time value corresponding to a unified timestamp; generating a common time field based on the coordinated time value and the reference time zone offset; generating a local time field based on the coordinated time value and the local time zone offset; and generating a time zone offset field based on the difference between the local time zone offset and the reference time zone offset. Further, the date offset field is generated by the terminal or server reading the time value corresponding to the local time field and the time value corresponding to the common time field.

[0015] The date sequence number of the local date is determined from the time value corresponding to the local time field, and the date sequence number of the common date is determined from the time value corresponding to the common time field; the date difference between the date sequence number of the local date and the date sequence number of the common date is calculated to obtain the date offset field; wherein, when the date offset field is positive, it indicates that the local date is later than the common date; when the date offset field is negative, it indicates that the local date is earlier than the common date; when the date offset field is zero, it indicates that the local date is the same as the common date.

[0016] In one possible implementation, the event time record may include an event identifier, a common time field, a local time field, a common time base time zone, the location's time zone, a time zone offset field, a date offset field, a time synchronization source identifier, a time zone source identifier, a time zone rule version, and a field generation time. The event identifier is used to associate with meeting events, flight events, transaction events, contract fulfillment events, or task triggering events, and the field generation time is used to record the time when the event time record is written to or updated.

[0017] In one possible implementation, when responding to an event display request, the terminal or server reads the common time field, the local time field, the time zone offset field, and the date offset field, uses the common time field as the unified time display item, the local time field as the local time display item, and the time zone offset field and the date offset field as auxiliary description items, generating a localized display result that simultaneously includes both unified time and local time.

[0018] In one possible implementation, when responding to an event sorting request, the terminal or server sorts multiple pending events in ascending or descending order according to the common time field, generating a sorting result. When responding to a time consistency verification request, the terminal or server recalculates candidate local times based on the common time field, the local time zone, and the time zone offset field, and compares the candidate local times with the local time field to generate a verification result including a verification pass flag or a verification exception reason.

[0019] In one possible implementation, when the same event to be processed is associated with multiple local time zones, the terminal or server generates a corresponding local time field, time zone offset field, and date offset field for each local time zone, and associates the local time field, time zone offset field, and date offset field corresponding to the multiple local time zones as multiple localized time sub-records with the same common time field and writes them into the event time record.

[0020] Secondly, this application provides a time zone common time processing system for implementing a time zone common time processing method as described in any of the above embodiments. The system includes a time synchronization acquisition module, a local time zone acquisition module, a common reference reading module, a dual reference field generation module, an event record writing module, and an event processing output module. The time synchronization acquisition module is used to acquire the system time synchronization time corresponding to the event to be processed; the local time zone acquisition module is used to acquire the local time zone corresponding to the terminal or the event to be processed; the common reference reading module is used to read a pre-configured common time reference time zone, which is a time zone selected from multiple candidate time zones, used to uniformly map the local time of events to be processed corresponding to different local time zones to the common time field under the common time reference time zone, and to serve as the time reference for the unified display, sorting, and verification of the events to be processed; the dual reference field generation module is used to perform time zone conversion based on the system time synchronization time, the local time zone, and the common time reference time zone, generating a common time field, a local time field, a time zone offset field, and a date offset field for the event to be processed, wherein the date offset field is used for... The local time field represents the offset relationship between the date corresponding to the local time field and the date corresponding to the common time field; the event record writing module is used to write the common time field, the local time field, the time zone offset field, and the date offset field into the event time record of the event to be processed; the event processing output module is used to read the event time record in response to the event display request, event sorting request, or time consistency verification request for the event to be processed, and when the request is an event display request, output the same common time field to multiple terminals corresponding to different local time zones, and use the common time field as a unified time display item; establish a unified timeline based on the common time field, and output localized display results, sorting results, or verification results based on the local time field, the time zone offset field, and the date offset field.

[0021] Compared with related technologies, this application has the following advantages:

[0022] In general, this application obtains the system time synchronization time, local time zone, and pre-configured common time reference time zone corresponding to the event to be processed, and generates a common time field, local time field, time zone offset field, and date offset field based on the above data and writes them into the event time record. This allows the unified processing basis, local display basis, and cross-day relationship of cross-time zone events to be saved and read in the form of fields. When responding to event display requests, event sorting requests, or time consistency verification requests in the future, the system can perform display, sorting, and verification processing around the same event time record, thereby reducing the time reference confusion, sorting misalignment, and inconsistent verification basis caused by a single local time field in cross-time zone scenarios.

[0023] First, by obtaining the system time synchronization time and the local time zone of the terminal or the location of the event to be processed, and reading the pre-configured common time reference time zone, subsequent time zone conversions simultaneously have basic time synchronization data, local time zone interpretation conditions, and a unified processing benchmark. Based on this, time zone conversions are performed according to the system time synchronization time, the local time zone, and the common time reference time zone to generate a common time field and a local time field. This ensures that the same event to be processed simultaneously has a common time basis for unified sorting and time consistency verification, as well as a local time basis for local users to understand. This avoids inconsistencies in time benchmarks caused by different terminals or different business modules interpreting the same event time value according to the local time zone, account time zone, or server time zone, and reduces the risk of display misunderstandings and sorting misalignments when cross-time zone events rely solely on a single local time for recording, display, or comparison.

[0024] Second, by generating time zone offset and date offset fields simultaneously with the common time field and local time field, the offset relationship between the local time zone and the common time reference time zone, as well as the cross-day relationship between the local date and the common date, can be recorded in a field-based manner. Furthermore, by writing the common time field, local time field, time zone offset field, and date offset field into the event time record of the event to be processed, these fields are not merely temporary display text, but rather data structures that can be read by subsequent event display requests, event sorting requests, and time consistency verification requests. This avoids the problem of missing dates that are one day earlier or later when only the hour is converted during cross-time zone conversion, and improves the consistency of data sources during cross-time zone event display, sorting, and verification.

[0025] Third, by responding to event display requests, event sorting requests, or time consistency verification requests, the system reads event time records and establishes a unified timeline based on a common time field. It then outputs localized display results, sorting results, or verification results based on local time fields, time zone offset fields, and date offset fields. This creates a closed processing chain between the field generation step and subsequent event processing steps, thereby improving the display consistency, sorting consistency, and time verification consistency of cross-time zone events on the terminal or server. Furthermore, when the same event to be processed is associated with multiple local time zones, the system generates corresponding local time fields, time zone offset fields, and date offset fields for each local time zone and writes them as multiple localized time sub-records associated with the same common time field in the event time record. This allows the same cross-time zone event to output corresponding localized times to different local objects, while still using the same common time field as the basis for unified sorting and verification in the background, thereby improving the consistency of cross-time zone event processing for multiple recipients. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments are briefly described below. Obviously, the accompanying drawings described below are only some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0027] Figure 1 A flowchart illustrating a time zone common time processing method provided in an embodiment of this application;

[0028] Figure 2 A schematic diagram of a data structure for event time recording provided in an embodiment of this application;

[0029] Figure 3 A schematic diagram illustrating the conversion between a common time field and a local time field, provided for an embodiment of this application;

[0030] Figure 4 A schematic diagram of the call flow for event display, event sorting, and time consistency verification provided in an embodiment of this application;

[0031] Figure 5 A schematic diagram of a time zone common time processing system provided in this application embodiment;

[0032] Figure 6 This is a schematic diagram of a scenario for time zone common time processing provided in an embodiment of this application. Detailed Implementation

[0033] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are only some embodiments of this application, and not all embodiments. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the protection scope of this application.

[0034] It should be noted that the terms "first" and "second" in the embodiments of this application are only used to distinguish similar objects and are not used to limit a specific order or priority. Unless otherwise stated, "common time," "unified time," and "same time" in this application are all used to describe a unified timing time based on a common time reference time zone; the "common time field" is used uniformly in field names and data structures. "Local time" is used to describe the local timing time based on the time zone of the terminal's location or the time zone of the event's location.

[0035] The unified time processing referred to in this application means pre-configuring a common time base zone, so that the local time of events to be processed corresponding to different location time zones is mapped to a common time field under the common time base zone, and the common time field is used as a unified time display item when the event is displayed. The common time base zone can be selected from candidate time zones according to business needs, and is not limited to the time zone of a specific country or region.

[0036] like Figure 1 As shown in the illustration, this application provides a method for processing shared time zones. This method can be executed by a terminal, a server, or both. The terminal can be a mobile phone, tablet computer, personal computer, conference terminal, flight check-in terminal, or vehicle-mounted terminal; the server can be a schedule server, transaction server, message server, scheduling server, or log server.

[0037] In this application embodiment, the event to be processed can be an event that needs to be recorded, displayed, sorted, reminded, verified, or triggered. For example, the event to be processed can be a multinational conference, a cross-border order, flight take-off and landing, contract fulfillment milestones, remote tasks, system logs, message sending tasks, or scheduled tasks. This application does not limit the business type of the event to be processed; as long as the event requires time understanding, display, or processing across different time zones, the method of this application can be applied.

[0038] Step S101: Obtain the system time synchronization corresponding to the event to be processed, and obtain the time zone of the terminal or the location corresponding to the event to be processed.

[0039] The system time synchronization can be the base time data that the terminal or server can read. This system time synchronization can originate from the operating system clock, network time synchronization service, business server time synchronization interface, or event creation interface. For example, when a user initiates a multinational conference in Beijing, the terminal can read the current time from the operating system; when a server receives a cross-border order, the server can use the time returned by the server time synchronization interface as the system time synchronization; when a task is pushed by an external system, the creation time carried by the external system in the event creation interface can also be read.

[0040] The system time synchronization time can include at least one of the following: timestamp, date, hours, minutes, seconds, and time zone identifier. When the system time synchronization time is a unified timestamp, the terminal or server can directly use it as the base time for subsequent time zone conversion; when the system time synchronization time is a local date and local time, the terminal or server reads the source time zone corresponding to the system time synchronization time and parses the local date and local time into a unified timestamp; when the system time synchronization time already carries a time zone identifier, the terminal or server parses the system time synchronization time according to the time zone identifier.

[0041] In one implementation, when multiple time synchronization sources exist, the terminal or server can select a time synchronization source according to the priority of the service server time synchronization interface, network time synchronization service, and operating system clock. The service server time synchronization interface can return the synchronization time, the time synchronization source identifier, and the interface return time; the network time synchronization service can return the network time synchronization time and the time synchronization service identifier; the operating system clock can return the local system time and the terminal time zone identifier. The terminal or server records the selected time synchronization source identifier in the event time record so that the time synchronization source of the event time record can be confirmed during subsequent verification.

[0042] The location time zone can be the time zone of the terminal's location or the time zone corresponding to the location of the event to be processed. The terminal's location time zone can be read from the terminal's system settings; the location time zone corresponding to the event to be processed can be read from the event creator's account configuration, the event receiver's account configuration, the event location information, the business organization configuration, or information manually entered by the user. For example, for remote meetings, the location time zone can include the account time zone of each participant; for flight events, the location time zone can include the time zone of the departure airport and the arrival airport; for cross-border orders, the location time zone can include the buyer's location time zone and the seller's location time zone.

[0043] In one implementation, when multiple timezone sources correspond to inconsistent timezones, the location timezone can be determined according to the priority of the event-specified timezone, user account timezone, event location timezone, and terminal system timezone. The event-specified timezone is the timezone explicitly written during event creation or editing; the user account timezone is the timezone saved in the user account information; the event location timezone is the timezone matched based on the event location identifier; and the terminal system timezone is the timezone currently set by the terminal's operating system. Using this priority can reduce the impact on event time recording caused by temporary terminal roaming or incorrect system timezone settings.

[0044] Step S102: Read the pre-configured common time base time zone.

[0045] A common time base zone is used as the time reference for unified sorting and verification of events in different time zones. The common time base zone is the foundation for implementing unified time, common time, or simultaneous time processing in this application. Through this base, local times in different time zones are no longer used as the sole basis for internal system sorting and triggering, but are instead uniformly mapped to a common time field under the common time base zone.

[0046] While the common time base zone remains valid, all pending events corresponding to different location time zones will generate a common time field based on the common time base zone. This allows the common time field to serve as the time basis for unified display, sorting, and verification across different location time zones. For example, Beijing time, Coordinated Universal Time, Tokyo time, London time, or the headquarters time zone designated by the business organization can be configured as the common time base zone. Once the common time base zone is selected, all pending events within the corresponding applicable scope will generate a common time field according to that common time base zone.

[0047] In one implementation, the terminal or server can read the common time base time zone from a common time base configuration table. The common time base configuration table may include a configuration identifier, service type, common time base time zone, time zone offset, time zone rule version, effective start time, effective end time, and configuration status. For example, the time zone name can be Beijing time, Coordinated Universal Time (UTC), Tokyo time, London time, or the headquarters time zone specified by a business organization; the time zone offset can be expressed in minutes relative to UTC; the service type can be conference service, order service, flight service, contract service, or log service; and the configuration status can be enabled or disabled.

[0048] In one implementation, the common time base configuration table can be generated during system initialization, business type creation, or when a business organization activates cross-time zone event processing functionality. The terminal or server receives a common time base setting request, which includes the business type, candidate time zone, applicable scope of the time base, and effective time range. Based on the business type, it determines the set of events that need to be uniformly sorted and verified, and reads the corresponding time zone offset and time zone rule version based on the candidate time zone. It writes the business type, the candidate time zone, the time zone offset, the time zone rule version, and the effective time range into the common time base configuration table, generating a corresponding configuration row, and sets the configuration status of the configuration row to enabled. The applicable scope of the time base may include meeting services, order services, flight services, contract fulfillment services, or log services, and the effective time range may include an effective start time and an effective end time. When no effective end time is set, the terminal or server determines that the configuration row is valid continuously from the effective start time.

[0049] In one implementation, when a historical configuration line for the same service type already exists in an enabled state, the terminal or server reads the effective start time and effective end time of the historical configuration line before writing a new configuration line, and updates the effective end time of the historical configuration line to the effective start time of the new configuration line, or updates the configuration status of the historical configuration line to disabled; then, the new configuration line is written. The already generated event time records retain the common time reference zone, reference time zone offset, and time zone rule version used when they were written; the new configuration line is only used for subsequently generated event time records.

[0050] In one implementation, system administrators, business organization administrators, or event creators can set a common time base time zone through a configuration interface. The configuration interface includes a business type selection option, a candidate time zone selection option, an effective start time input option, an effective end time input option, and a configuration confirmation option. In response to the configuration confirmation operation, the terminal or server reads the business type selection option, the candidate time zone selection option, and the effective time range, and verifies whether the candidate time zone exists in the time zone rule base. If the candidate time zone exists in the time zone rule base, it reads the corresponding time zone offset and time zone rule version, and generates a configuration row in the common time base configuration table. If the candidate time zone does not exist in the time zone rule base, a configuration failure message is output, and writing the candidate time zone into the common time base configuration table is prohibited.

[0051] For example, in a multinational conference service, the system administrator selects "Multinational Conference Service" as the service type, "Beijing Time" as the candidate reference time zone, sets the effective start time to 00:00 on January 1, 2018, and does not set an effective end time. The server reads the reference time zone offset corresponding to Beijing time from the time zone rule base as +480 minutes and reads the current time zone rule version as R001. The server writes the configuration identifier C001, service type "Multinational Conference Service", common time reference time zone "Beijing Time", reference time zone offset +480 minutes, time zone rule version R001, effective start time 00:00 on January 1, 2018, effective end time empty, and configuration status "Enabled" into the common time reference configuration table. When the server subsequently processes multinational conference events, it queries this configuration table using the event service type and event creation time, and uses the Beijing time corresponding to configuration identifier C001 as the common time reference time zone.

[0052] In one implementation, when the common time base configuration table is changed, the revised common time base time zone only applies to event time records generated after the change. Previously generated event time records retain the common time base time zone and time zone rule version used during their generation. This avoids the common time field from being reinterpreted due to changes in the common time base time zone, thus preventing disruptions to the sorting, display, or validation of historical events.

[0053] Step S103: Perform time zone conversion based on system time synchronization time, local time zone, and common time reference time zone to generate common time field, local time field, time zone offset field, and date offset field for the event to be processed.

[0054] In this step, the terminal or server first converts the system time synchronization time into a unified timestamp. The unified timestamp can be a standard timestamp, a Coordinated Universal Time (UTC) corresponding timestamp, or a time value uniformly stored internally by the system. This application does not limit the specific encoding format of the unified timestamp, as long as it can represent the same instant and can be used for conversion between different time zones.

[0055] Before performing time zone conversion, the terminal or server can read the time zone rule base. The time zone rule base can include time zone identifiers, rule versions, effective date ranges, and time zone offsets. The terminal or server reads the local time zone offset and the reference time zone offset from the time zone rule base based on the corresponding date and system time synchronization time. Therefore, even if the same location has different time zone offsets on different dates, the actual offset for that date can be determined using the time zone rule base.

[0056] When the local time zone offset is ZL, the common time reference time zone offset is ZC, and the UTC time value corresponding to the unified timestamp is TU, the terminal or server can obtain the local time TL and the common time TC according to the following formula:

[0057]

[0058]

[0059] Wherein, TL represents the time value corresponding to the local time field; TU represents the UTC time value corresponding to the unified timestamp; ZL represents the offset of the local time zone relative to the UTC time value; TC represents the time value corresponding to the common time field; and ZC represents the offset of the common time base time zone relative to the UTC time value. These offsets can be in hours, minutes, or seconds, and the units must be consistent within the same system.

[0060] The time zone offset field can be generated based on the offset difference between the local time zone and the common time base time zone. For example, it can be calculated as follows:

[0061]

[0062] Wherein, DZ represents the offset value corresponding to the time zone offset field. When DZ is positive, it means that the time zone corresponding to the local time field is later than the common time base time zone; when DZ is negative, it means that the time zone corresponding to the local time field is earlier than the common time base time zone; when DZ is zero, it means that the time zone corresponding to the local time field is the same as the common time base time zone.

[0063] The date offset field represents the offset relationship between the local time field and the common time field. Terminals or servers can compare the local date in the local time field and the common date in the common time field. The date offset field can be generated as follows:

[0064] .

[0065] Wherein, DD represents the date offset field; Date(TL) represents the date sequence number in the local time field; and Date(TC) represents the date sequence number in the common time field. If DD is positive, it indicates that the local date is later than the common date; if DD is negative, it indicates that the local date is earlier than the common date; and if DD is zero, it indicates that the local date and the common date are the same. The date sequence number can be represented by the system's internal date sequence number that can perform date difference calculations, or it can be represented by a date object that can calculate date differences.

[0066] Taking Beijing time as the common time reference zone as an example, if the common time field is 2018 / 10 / 8 9:50, and the location time zone is Tokyo, then the local time field can be 2018 / 10 / 8 10:50, the time zone offset field can be +1 hour, and the date offset field can be 0 days. If the location time zone is London, then the local time field can be 2018 / 10 / 8 1:50, the time zone offset field can be -8 hours, and the date offset field can be 0 days. If the location time zone is New York, then the local time field can be 2018 / 10 / 7 20:50, the time zone offset field can be -13 hours, and the date offset field can be -1 day. In this way, the same event has both a common time under a unified time definition and a local time that can be understood by users in different regions.

[0067] Step S104: Write the common time field, local time field, time zone offset field, and date offset field into the event time record of the event to be processed.

[0068] like Figure 2As shown, an event time record can include an event identifier, a common time field, a local time field, a common time base time zone, the local time zone, a time zone offset field, a date offset field, a time synchronization source identifier, a time zone source identifier, a time zone rule version, and a field generation time. The event identifier is used to uniquely or relatively uniquely identify the event to be processed. The common time field is used to establish a unified timeline; the local time field is used for localized display; the common time base time zone is used to describe the reference for the common time field; the local time zone is used to describe the reference for the local time field; the time zone offset field is used to describe the difference between the local time zone and the common time base time zone; the date offset field is used to indicate whether the local date crosses a day relative to the common date; the time synchronization source identifier is used to record the source of the system's time synchronization; the time zone source identifier is used to record the source of the local time zone; the time zone rule version is used to record the time zone rule version called during conversion; and the field generation time is used to record the time when the event time record was written or updated.

[0069] In one implementation, event time records can be stored as database records, key-value pairs, message body fields, log fields, or cached records. For example, for a conference system, event time records can be written to a conference schedule table; for a transaction system, event time records can be written to an order event table; for a scheduling system, event time records can be written to a task team list; and for a log system, event time records can be written to a log index table. This application does not limit the specific storage medium and table structure of the event time records, only requiring that the common time field, local time field, time zone offset field, and date offset field can be read by subsequent processing.

[0070] In one implementation, when the same event to be processed is associated with multiple local time zones, the event time records can be set up as a common time master record and multiple localized time sub-records. The common time master record includes an event identifier, a common time field, a common time base time zone, a base time zone offset, and a time zone rule version; each localized time sub-record includes a local time zone, a local time field, a time zone offset field, a date offset field, and a display object identifier. The display object identifier can be a user identifier, a terminal identifier, a location identifier, or a business participant identifier. With this structure, the same cross-time zone event can retain only one common time field, while generating different localized time information for different recipients.

[0071] For example, the event to be processed is a multinational conference event, with the event identifier M001. The common time base zone for the conference is Beijing time. The common time field generated by the server based on the system time synchronization time and the common time base zone is 2018 / 10 / 8 9:50, the common time base zone is Beijing time, the base time zone offset is +480 minutes, and the time zone rule version is R001. The server writes the event identifier M001, the common time field 2018 / 10 / 8 9:50, the common time base zone "Beijing time", the base time zone offset +480 minutes, and the time zone rule version R001 into the common time master record.

[0072] When a multinational conference event is associated with participants from Tokyo, London, and New York, the server generates a localized time sub-record based on each participant's location timezone. For Tokyo participants, the location timezone is Tokyo time, the local time field is 2018 / 10 / 8 10:50, the timezone offset field is +1 hour, the date offset field is 0 days, and the displayed object identifier is the Tokyo participant's user ID. For London participants, the location timezone is London time, the local time field is 2018 / 10 / 8 1:50, the timezone offset field is -8 hours, the date offset field is 0 days, and the displayed object identifier is the London participant's user ID. For New York participants, the location timezone is New York time, the local time field is 2018 / 10 / 7 20:50, the timezone offset field is -13 hours, the date offset field is -1 day, and the displayed object identifier is the New York participant's user ID. The three localized time sub-records mentioned above are all stored in association with the event identifier M001 and the common time field 2018 / 10 / 8 9:50.

[0073] When the server responds to a conference sorting request, it reads the common time master record corresponding to event identifier M001 and writes the multinational conference event into the unified timeline according to the common time field 2018 / 10 / 8 9:50. When a participant in Tokyo responds to an event display request, it reads the Tokyo localized time sub-record corresponding to the display object identifier and outputs "Unified Time: 2018 / 10 / 8 9:50; Local Time: 2018 / 10 / 8 10:50 (Tokyo, +1 hour, 0 days)". When a participant in New York responds to an event display request, it reads the New York localized time sub-record corresponding to the display object identifier and outputs "Unified Time: 2018 / 10 / 8 9:50; Local Time: 2018 / 10 / 7 20:50 (New York, -13 hours, -1 day)". Therefore, the same pending event uses the same common time field when sorted in the background, and uses the corresponding local time field, time zone offset field, and date offset field when displayed on terminals in different locations.

[0074] Step S105: In response to an event display request, event sorting request, or time consistency verification request for the event to be processed, read the event time record, and when the request is an event display request, output the same common time field to multiple terminals corresponding to different local time zones, and use the common time field as a unified time display item; establish a unified timeline based on the common time field, and output localized display results, sorting results, or verification results based on the local time field, the time zone offset field, and the date offset field.

[0075] like Figure 6 As shown, in one implementation, after the terminal or server reads the event time record corresponding to the event to be processed, it can enter three processing branches according to different request types: event display, event sorting, and time consistency verification. The event time record includes a common time field, a local time field, a time zone offset field, and a date offset field. In the event display branch, the terminal or server reads the corresponding fields according to the display mode identifier and outputs display results containing both the unified time and local time to user terminals in different locations. In the event sorting branch, the terminal or server reads the common time field from multiple event time records and establishes a unified timeline accordingly. In the time consistency verification branch, the terminal or server recalculates candidate local times based on the common time field, the common time reference time zone, the local time zone, and the time zone offset field, and compares the candidate local times with the local time field to output a verification pass flag or a verification failure record. Thus, event display, event sorting, and time consistency verification all revolve around the same event time record and respectively call different fields within it.

[0076] When responding to an event display request, the terminal or server reads the common time field, local time field, time zone offset field, and date offset field from the event time record. When the same event to be processed corresponds to multiple display objects in different local time zones, the terminals corresponding to each display object read the same common time field and use it as the unified time display item; each terminal uses the local time field corresponding to its own local time zone as the local time display item, and uses the time zone offset field and the date offset field as auxiliary description items. For example, the display result may include "Unified Time: 2018 / 10 / 8 9:50 (Beijing Time); Local Time: 2018 / 10 / 7 20:50 (New York, -13 hours, -1 day)". Through this display method, users can simultaneously see the common time used by the system for unified processing, as well as the local time that their location needs to understand and execute.

[0077] In one implementation, the event display request may carry a display mode identifier. Display modes may include common time priority mode, local time priority mode, and two-line display mode. In common time priority mode, the common time field is displayed first, followed by the local time field; in local time priority mode, the local time field is displayed first, followed by the common time field; in two-line display mode, the common time field and the local time field are displayed in two separate display lines, with the time zone offset field and date offset field displayed after the local time field. Regardless of the display mode used, the displayed content is read from the event time record, and unrecorded time fields are not regenerated.

[0078] When responding to an event sorting request, the terminal or server reads multiple event time records and sorts the multiple pending events according to a common time field. Since all events are mapped to the same common time base time zone, the system can directly establish a unified timeline based on the common time field, avoiding errors in the sequential relationship caused by directly sorting events from different local times. For example, a meeting created by a user in Beijing, a meeting created by a user in London, and a task created by a user in New York can all be sorted in the same list using the common time field.

[0079] A unified timeline refers to an event time series obtained by arranging multiple event time records in ascending or descending order based on a common time field from the terminal or server. Ascending order can be used to generate a list of upcoming events; descending order can be used to generate a list of historical events. Events with the same common time field can be further sorted by event creation time, event priority, or event identifier.

[0080] For example, the server stores the event timestamps of three pending events. The first pending event is a multinational conference event created by a user in Beijing, identified as M001. The shared time field is 2018 / 10 / 8 9:50, the local time field is 2018 / 10 / 8 9:50, the location timezone is Beijing time, the timezone offset field is 0 hours, and the date offset field is 0 days. The second pending event is a remote task event created by a user in London, identified as T002. The shared time field is 2018 / 10 / 8 10:20, the local time field is 2018 / 10 / 8 2:20, the location timezone is London time, the timezone offset field is -8 hours, and the date offset field is 0 days. The third pending event is a transaction confirmation event created by a user in New York, identified as O003. The shared time field is 2018 / 10 / 8 8:40, the local time field is 2018 / 10 / 7 19:40, the location timezone is New York time, the timezone offset field is -13 hours, and the date offset field is -1 day.

[0081] When a New York user's terminal initiates an event display request for event identifier O003, and the display mode identifier carried in the event display request is local time priority mode, the terminal reads the event time record corresponding to event identifier O003, first displays the local time field 2018 / 10 / 7 19:40, then displays the common time field 2018 / 10 / 8 8:40, and displays "New York Time, -13 hours, -1 day" after the local time field. When the display mode identifier is common time priority mode, the terminal first displays the common time field 2018 / 10 / 8 8:40, then displays the local time field 2018 / 10 / 7 19:40. When the display mode identifier is two-line display mode, the terminal displays "Uniform Time: 2018 / 10 / 8 8:40" on the first display line and "Local Time: 2018 / 10 / 7 19:40 (New York, -13 hours, -1 day)" on the second display line.

[0082] When the server responds to an event sorting request, it reads the event time records corresponding to event identifiers M001, T002, and O003, and extracts the common time fields 2018 / 10 / 8 9:50, 2018 / 10 / 8 10:20, and 2018 / 10 / 8 8:40 respectively. If the event sorting request carries an ascending order identifier, the server sorts them from earliest to latest according to the common time field, resulting in a list of upcoming events arranged in the order of event identifiers O003, M001, and T002. If the event sorting request carries a descending order identifier, the server sorts them from latest to earliest according to the common time field, resulting in a list of historical or reverse-order events arranged in the order of event identifiers T002, M001, and O003. Therefore, even if the three events correspond to local times in Beijing, London, and New York respectively, the server still establishes a unified timeline based on the common time field, avoiding errors in the chronological order of events across time zones caused by directly sorting based on the local time field.

[0083] When responding to a time consistency verification request, the terminal or server reads the event time record, recalculates the candidate local time based on the common time field, common time base time zone, local time zone, and time zone offset field, and compares the candidate local time with the local time field. If they match, a verification pass flag is output; if they do not match, the reason for the verification error is output. Reasons for verification errors may include a missing common time field, a missing local time field, a missing local time zone, an incorrect time zone offset field, an incorrect date offset field, or an incorrect local time conversion.

[0084] In one implementation, when time consistency verification fails, the terminal or server can prevent the direct overwriting of the original common time field and output a verification error record requiring manual review. Manual review can be used to confirm whether the common time reference time zone configuration is correct, whether the local time zone source is correct, whether the time zone rule version needs updating, or whether the event time needs to be regenerated. This process prevents erroneous fields from being automatically overwritten and affecting the unified timeline of events across time zones.

[0085] For example, the event time record corresponding to the transaction confirmation event with event identifier O003 contains the following: common time field: 2018 / 10 / 8 8:40; common time base time zone: Beijing time; location time zone: New York time; time zone offset field: -13 hours; local time field: 2018 / 10 / 7 19:40; date offset field: -1 day. When the terminal or server responds to the time consistency verification request, it reads the common time field, the common time base time zone, the location time zone, and the time zone offset field, and recalculates the candidate local time based on the common time field 2018 / 10 / 8 8:40 and the time zone offset field -13 hours, obtaining the candidate local time as 2018 / 10 / 7 19:40. The terminal or server compares the candidate local time with the local time field 2018 / 10 / 7 19:40 in the event time record. Since they are consistent, a verification pass flag is output, and the event time record is allowed to continue participating in event display and event sorting.

[0086] For example, if the local time field in the event time record with event identifier O003 is incorrectly written as 2018 / 10 / 8 19:40, while the common time field remains 2018 / 10 / 8 8:40, the local time zone remains New York time, and the time zone offset field remains -13 hours, then the candidate local time recalculated by the terminal or server will still be 2018 / 10 / 7 19:40. The terminal or server compares the candidate local time 2018 / 10 / 7 19:40 with the local time field 2018 / 10 / 8 19:40, determines that the two are inconsistent, and outputs the verification exception reason. The verification exception reason includes at least one of local time conversion error and date offset field error. At this time, the terminal or server is prohibited from directly overwriting the common time field and generates a verification error record. The verification error record includes event identifier O003, the common time field 2018 / 10 / 8 8:40, the local time zone (New York time), the original local time field 2018 / 10 / 8 19:40, the candidate local time 2018 / 10 / 7 19:40, the original date offset field, and the recalculated date offset value. After manually reviewing the verification error record, the reviewer can confirm whether the source of the local time zone, the time zone rule version, and the common time reference time zone are correct. After confirming the source of the error, the reviewer can regenerate the local time field, time zone offset field, or date offset field without changing the unified timeline position corresponding to the original common time field.

[0087] like Figure 3 As shown, the same common time field can correspond to multiple local time fields. Figure 3 In this system, the common time base is Beijing time; the first location's time zone is Tokyo, the second is London, and the third is New York. The terminal or server generates Tokyo local time, London local time, and New York local time fields respectively, along with corresponding time zone offset and date offset fields. Thus, the same event can be processed in the background using a unified time, while being displayed in the respective local time on different user terminals.

[0088] like Figure 4 As shown, event display, event sorting, and time consistency verification all read event time records, but they read different fields and output different results. Event display reads the common time field and the local time field, and outputs a localized display result; event sorting mainly reads the common time field and outputs the sorting result; time consistency verification reads the common time field, the local time field, the time zone offset field, and the date offset field, and outputs the verification result. Since each process revolves around the event time record, all the fields generated above participate in subsequent processing, and there are no intermediate fields that are only generated and not used.

[0089] like Figure 5As shown in the illustration, this application also provides a time zone common time processing system. This system can be deployed on a terminal, a server, or partially on both. The system includes a time synchronization acquisition module, a local time zone acquisition module, a common reference reading module, a dual reference field generation module, an event log writing module, and an event processing output module.

[0090] The time synchronization acquisition module is used to obtain the system time synchronization time corresponding to the event to be processed. The local time zone acquisition module is used to obtain the local time zone corresponding to the terminal or the event to be processed. The common reference reading module is used to read the pre-configured common time reference time zone. The dual reference field generation module is used to perform time zone conversion based on the system time synchronization time, local time zone, and common time reference time zone to generate the common time field, local time field, time zone offset field, and date offset field of the event to be processed. The event record writing module is used to write the common time field, local time field, time zone offset field, and date offset field into the event time record of the event to be processed. The event processing output module is used to respond to event display requests, event sorting requests, or time consistency verification requests, read the event time record, establish a unified timeline based on the common time field, and output localized display results, sorting results, or verification results based on the local time field, time zone offset field, and date offset field.

[0091] Establishing a unified timeline based on the common time field includes: reading the common time field corresponding to each of the multiple events to be processed, and arranging the multiple events to be processed in ascending or descending order according to the date and time represented by the common time field to form an event time sequence arranged in chronological order.

[0092] In one embodiment, a common time zone processing system may further include a time zone rule reading module and a configuration management module. The time zone rule reading module reads the local time zone offset and the reference time zone offset from the time zone rule base. The configuration management module generates, modifies, and disables configuration rows in the common time reference configuration table, and records the configuration change time and the object of the configuration operation. Changes to the common time reference configuration table by the configuration management module only affect the event time records generated after the change; already generated event time records retain the original common time reference time zone and time zone rule version.

[0093] like Figure 6 As shown in the illustration, this application also provides an electronic device. This electronic device may include a processor, a memory, a communication interface, and a bus. The processor, memory, and communication interface can be connected via the bus. The memory stores a computer program; when the processor loads and executes the computer program, it can implement the aforementioned time zone common time processing method. The communication interface can be used to communicate with a time synchronization server, a service server, a user terminal, or a database.

[0094] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the aforementioned time zone common time processing method. The computer-readable storage medium can be a read-only memory, random access memory, magnetic disk, optical disk, flash memory, or other medium capable of storing a computer program.

[0095] It should be noted that the steps in the above embodiments can be combined or separated according to the actual business process, but the main technical chain of using a common time field for unified time display and unified timeline processing, and using local time fields, time zone offset fields, and date offset fields for localized display or verification should remain unchanged. This application pre-configures a common time reference time zone so that events to be processed corresponding to different local time zones generate a common time field represented by the common time reference time zone, and further fields and records the common time reference and local time reference, so that they play their respective roles in event display, event sorting, and time consistency verification, thereby forming a time zone common time processing mechanism suitable for terminals or servers.

[0096] The above description is merely a preferred embodiment of this application. It should be noted that, due to the limitations of written expression, there are objectively infinite specific structures. For those skilled in the art, without departing from the principles of this application, several improvements, modifications, or variations can be made, and the above technical features can be combined in an appropriate manner. These improvements, modifications, variations, or combinations, or the direct application of the concept and technical solution of this application to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A time zone common time processing method, applied to a terminal or server, the method comprising: Obtain the system time synchronization corresponding to the event to be processed, and obtain the time zone of the terminal or the location corresponding to the event to be processed; Read the pre-configured common time reference time zone, which is a time zone selected from multiple candidate time zones. It is used to uniformly map the local time of the events to be processed corresponding to different local time zones to the common time field under the common time reference time zone, and to serve as the time reference for the unified display, sorting and verification of the events to be processed. Based on the system time synchronization time, the local time zone, and the common time reference time zone, a time zone conversion is performed to generate a common time field, a local time field, a time zone offset field, and a date offset field for the event to be processed. The date offset field is used to characterize the offset relationship between the date corresponding to the local time field and the date corresponding to the common time field. Write the common time field, the local time field, the time zone offset field, and the date offset field into the event time record of the event to be processed; In response to an event display request, event sorting request, or time consistency verification request for the event to be processed, the event time record is read, and when the request is an event display request, the same common time field is output to multiple terminals corresponding to different local time zones, and the common time field is used as a unified time display item; A unified timeline is established based on the common time field, and localized display results, sorting results, or verification results are output based on the local time field, the time zone offset field, and the date offset field.

2. The time zone common time processing method according to claim 1, characterized in that, Obtaining the local time zone corresponding to the terminal or the event to be processed includes: Read at least one of the following: the time zone specified for the event, the user account time zone, the event location time zone, and the terminal system time zone; When multiple time zone sources correspond to inconsistent time zones, the location time zone is determined according to the priority of the event-specified time zone, user account time zone, event location time zone, and terminal system time zone.

3. The time zone common time processing method according to claim 1, characterized in that, Read the pre-configured common time base time zone, including: The terminal or server reads the common time base time zone corresponding to the event to be processed from the common time base configuration table; The common time reference configuration table is generated during system initialization, business type creation, or when a business organization enables cross-time zone event processing. The configuration rows in the common time reference configuration table include business type, candidate reference time zone, reference time zone offset, time zone rule version, effective time range, and configuration status. The terminal or server selects a configuration row from the common time reference configuration table that is enabled and within the effective time range, based on the service type corresponding to the event to be processed, and determines the candidate reference time zone in the configuration row as the common time reference time zone.

4. The time zone common time processing method according to claim 1, characterized in that, Before performing time zone conversion, the time zone rule base is read, including: The terminal or server converts the system time synchronization into a unified timestamp and reads the time zone rule base; The time zone rule base includes a time zone identifier, rule version, effective date range, and time zone offset. The terminal or server reads the time zone offset corresponding to the local time zone and the time zone offset corresponding to the common time reference time zone from the time zone rule base according to the date corresponding to the local time zone, the common time reference time zone and the system time synchronization time, and uses the time zone offset corresponding to the local time zone as the local time zone offset and the time zone offset corresponding to the common time reference time zone as the reference time zone offset. The local time zone offset and the reference time zone offset are used to generate the common time field, the local time field, and the time zone offset field.

5. The time zone common time processing method according to claim 4, characterized in that, Time zone conversion is performed based on the system time synchronization time, the local time zone, and the common time reference time zone, including: Convert the system time synchronization time into a coordinated time value corresponding to a unified timestamp; The common time field is generated based on the coordinated time value and the reference time zone offset; The local time field is generated based on the coordinated time value and the local time zone offset; The time zone offset field is generated based on the difference between the local time zone offset and the reference time zone offset.

6. The time zone common time processing method according to claim 1, characterized in that, The date offset field is generated in the following way: The terminal or server reads the time value corresponding to the local time field and the time value corresponding to the common time field; The date sequence number of the local date is determined from the time value corresponding to the local time field, and the date sequence number of the common date is determined from the time value corresponding to the common time field; The date offset field is obtained by calculating the date difference between the date sequence number of the local date and the date sequence number of the common date; When the date offset field is positive, it indicates that the local date is later than the common date; When the date offset field is negative, it indicates that the local date is earlier than the common date; When the date offset field is zero, it indicates that the local date is the same as the common date.

7. The time zone common time processing method according to claim 1, characterized in that, In response to an event display request for the pending event, the event time record is read, including: Read the common time field, the local time field, the time zone offset field, and the date offset field; The common time field is displayed as the unified time, the local time field is displayed as the local time, and the time zone offset field and the date offset field are used as auxiliary descriptions to generate a localized display result that includes both unified time and local time.

8. The time zone common time processing method according to claim 1, characterized in that, In response to an event sorting request or a time consistency check request for the event to be processed, the event time record is read, including: When sorting events, multiple events to be processed are arranged in ascending or descending order according to the common time field to generate the sorting result. During time consistency verification, candidate local times are recalculated based on the common time field, the local time zone, and the time zone offset field. The candidate local times are then compared with the local time field to generate a verification result that includes a verification pass flag or a verification exception reason.

9. The time zone common time processing method according to claim 1, characterized in that, When the event to be processed is associated with multiple local time zones, a corresponding local time field, time zone offset field, and date offset field are generated for each local time zone. The local time field, time zone offset field, and date offset field corresponding to multiple local time zones are treated as multiple localized time sub-records and associated with the same common time field and written into the event time record.

10. A time zone common time processing system, characterized in that, The system is used to implement the time zone common time processing method according to any one of claims 1 to 9, the system comprising: The time synchronization acquisition module is used to acquire the system time synchronization time corresponding to the event to be processed; The local time zone acquisition module is used to acquire the local time zone corresponding to the terminal or the event to be processed; The common reference reading module is used to read a pre-configured common time reference time zone, which is a time zone selected from multiple candidate time zones. It is used to uniformly map the local time of the events to be processed corresponding to different local time zones to the common time field under the common time reference time zone, and to use it as the time reference for the unified display, sorting and verification of the events to be processed. The dual-reference field generation module is used to perform time zone conversion based on the system time synchronization time, the local time zone, and the common time reference time zone to generate a common time field, a local time field, a time zone offset field, and a date offset field for the event to be processed. The date offset field is used to characterize the offset relationship between the date corresponding to the local time field and the date corresponding to the common time field. The event log writing module is used to write the common time field, the local time field, the time zone offset field, and the date offset field into the event time record of the event to be processed; The event processing output module is used to respond to an event display request, event sorting request, or time consistency verification request for the event to be processed, read the event time record, and when the request is an event display request, output the same common time field to multiple terminals corresponding to different local time zones, and use the common time field as a unified time display item; establish a unified timeline based on the common time field, and output localized display results, sorting results, or verification results based on the local time field, the time zone offset field, and the date offset field.

Images