A method and apparatus for verifying a daylight savings time change

Abstract

The purpose of the present application is to provide a method and device for verifying the switching of summer and winter time, which realizes the embedding of the traditional verification logic depending on external test tools and manual intervention into the firmware runtime system of the device, and constructs a closed-loop summer time DST self-verification mechanism with the capabilities of rule analysis, event pre-play, execution monitoring, result comparison and abnormal response. The mechanism does not depend on network connection or external debugging interface, and can still complete the integrity check of the DST switching behavior independently when the device is in a completely offline state, thereby solving the problems of time confusion, data distortion and service interruption caused by the lack of self-checking capability in the prior art.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a verification method and device for switching between daylight saving time and winter time. Background Technology

[0002] The existing daylight saving time system refers to advancing or advancing the local time by one hour on a predetermined date to make more efficient use of sunlight. For smart devices that rely on precise timestamps (such as smartwatches that record health data, security cameras that trigger event recording, and pet collars that feed pets on a schedule), improper handling of DST (Daylight Saving Time) switching can lead to serious problems such as time discrepancies, data loss, and service failures.

[0003] In existing technologies, smart devices typically rely on cloud synchronization and static rule base modes to handle DST. Cloud synchronization involves the device obtaining the current time zone and DST status via NTP (Network Time Protocol) or the manufacturer's server. This method is effective when connected to the internet, but completely fails in airplane mode, remote areas, or when the network is down. Static rule base mode involves the device firmware having a built-in global time zone database (such as IANA tzdatabase). The current time zone rules are loaded when the system starts up, and the time is automatically adjusted at the time of switching. However, this mode can only "execute" the switch, but cannot "verify" whether the switch is successful or meets expectations.

[0004] Currently, manual testing is commonly used to verify DST functionality. During verification, test engineers need to log into the device via Telnet, manually execute the zdump command to query DST rules, and then use `date @xxx` to force the system time to be set before and after the switching threshold, observing whether the watermark or logs change. This manual testing method for verifying DST functionality has three technical drawbacks: First, it's not product-grade; the verification capability exists within the testing toolchain, not the device itself. Second, it lacks comprehensive coverage, failing to exhaustively cover boundary conditions for all time zones and years. Third, it has an offline blind spot; once the device is offline, its DST behavior becomes completely unobservable and unreliable.

[0005] In existing technologies, because devices cannot autonomously confirm whether the DST switching logic is working as expected without external intervention, online faults are difficult to reproduce and locate, and there is a lack of intrinsic verification mechanisms. Furthermore, in offline scenarios, devices may fail to switch DST due to rule parsing errors, system clock drift, or firmware bugs, and neither users nor manufacturers can detect this in time, resulting in a lack of reliability assurance. The efficient zdump+date testing method is only used on the production line and has not been transformed into the core capability of the product, resulting in a waste of R&D resources and a disconnect between user experience and testing. Summary of the Invention

[0006] One objective of this application is to provide a verification method and device for daylight saving time (DST) switching, which enables the device to autonomously complete the integrity verification of DST switching behavior in a completely offline state without relying on network connection or external debugging interface, thereby solving the problems of time disorder, data distortion and service interruption caused by lack of self-testing capability in the prior art.

[0007] According to one aspect of this application, a verification method for switching between winter and summer time is provided. This method is applied to the firmware runtime system of a device, wherein the method includes: During device startup or when the user actively modifies the system time zone configuration, the binary format of the Daylight Saving Time (DST) rule file corresponding to the target time zone of the current region is loaded. The DST rule file is parsed and effectively filtered in sequence to obtain all valid DST switching events and their event entries within a future preset time period; wherein, the device is currently in a network offline state. When the current system UTC time is equal to the UTC switching time in the event entry, the time zone switching logic is triggered to execute the operation. After the time zone switching operation of the device is completed, the measured offset between the current UTC reference time and the current local time is calculated. When the difference between the measured offset and the expected local offset in the event entry is within the preset tolerance range, the verification status in the event entry is marked as verified and the valid DST switching event corresponding to the verified event is deleted, and the DST rule file is parsed again. When the difference between the measured offset and the expected local offset in the event entry exceeds the preset tolerance range, the current time zone after the switch, the measured offset, and the system kernel version of the device are added to the event entry, and the updated event entry is written to the abnormal event entry queue.

[0008] Furthermore, in the above method, the step of sequentially parsing and effectively filtering the DST rule file to obtain all valid DST switching events and their event entries within a future preset time period includes: Iterate through each DST switching event in the DST rule file and perform structured parsing on each DST switching event to extract the UTC switching time, expected local offset, and boolean flag indicating whether daylight saving time is enabled for each DST switching event. Calculate the time difference between the current system UTC time and the UTC switching time of each DST switching event. If the time difference is within the preset time period in the future, the DST switching event is retained as a valid DST switching event, so as to obtain all valid DST switching events within the preset time period in the future. For each of the valid DST switching events, a corresponding event entry is constructed.

[0009] Furthermore, in the above method, the event entry for the valid DST handover event is a 32-byte record. The internal fields of this record are arranged with a fixed offset as follows: bytes 0 to 7 represent the UTC handover time, bytes 8 to 11 represent the expected local offset, the high 7 bits of the 12th byte represent the expected daylight saving time status, the least significant bit of the 12th byte is used to store and mark the verification status of the valid DST handover event, and bytes 13 to 31 are filled with 0 and reserved for expansion space. The initial value of the verification status of the valid DST handover event is used to indicate the identifier to be verified.

[0010] Furthermore, in the above method, after sequentially parsing and effectively filtering the DST rule file to obtain all valid DST switching events and their event entries within a future preset time period, the method further includes: All valid DST switching events and their event entries within the preset time period are arranged in ascending order of time and stored in a circular buffer. The pointer of the circular buffer is used to indicate the current write position and read position, and initially points to the starting address of the circular buffer. The underlying storage driver interface is invoked to write the entire contents of the circular buffer into a preset sector of the non-volatile storage area of ​​the device in the form of key-value pairs, and the write protection flag of the preset sector is set. The non-volatile storage area is the RPMB partition in the SPI NOR Flash or eMMC chip connected to the main control chip of the device. The physical address space of the non-volatile storage area is pre-allocated by the firmware linker script and mapped to the kernel virtual address space through the memory management unit (MMU). The non-volatile storage area only allows atomic write operations through a preset underlying storage driver interface.

[0011] Furthermore, in the above method, after sequentially parsing and effectively filtering the DST rule file to obtain all valid DST switching events and their event entries within a future preset time period, the method further includes: The system continuously polls the current system UTC time. When the difference between the current system UTC time and the UTC switching time in the event entry is within the first preset time difference, the system enters a high-sensitivity monitoring state and sends an instruction to the system's underlying clock driver to increase the system clock interrupt frequency from 1Hz to 10Hz. At the same time, a high-priority mask flag is registered with the task scheduler to prohibit the execution of all low-priority task scheduling that would cause modification of the system time or cause blocking.

[0012] Furthermore, in the above method, the step of triggering the time zone switching logic execution operation when the acquired current system UTC time is equal to the UTC switching time in the event entry includes: When the current system UTC time is equal to the UTC switching time in the event entry, read the expected local offset and expected daylight saving time status in the event entry; The kernel time subsystem interface is invoked to update the device's system local time offset to the calculated measured offset; simultaneously, the timestamp conversion tables of all application layer caches are refreshed.

[0013] Furthermore, in the above method, after adding the current time zone after the switch, the measured offset, and the system kernel version of the device to the event entry, and writing the updated event entry to the abnormal event entry queue, the method further includes: The exception event entry queue is a pre-reserved circular buffer in the log partition, managed using a FIFO strategy. When the circular buffer is full, the oldest record stored in the circular buffer is overwritten. At the same time, the preset DST fault flag bit in the SoC internal watchdog register is set. The preset DST fault flag bit is used to be polled and detected by the power management unit or security monitoring module of the device.

[0014] Furthermore, the above method further includes: When the device restores network connectivity, the device's communication module, according to the security policy configuration, reads the updated event entry corresponding to the valid DST switching event that was not uploaded and is used to indicate the abnormal record from the abnormal event entry queue, and uploads it to the manufacturer's diagnostic server corresponding to the device through a TLS encrypted channel. If the device is still offline, a degraded operating mode is triggered locally by suspending the data acquisition function that relies on precise timestamps, replacing the absolute timestamps with relative time counters, until the DST state is restored to a reliable state.

[0015] According to another aspect of this application, a non-volatile storage medium is also provided, on which computer-readable instructions are stored, which, when executed by a processor, cause the processor to implement the verification method for switching between daylight saving time as described above.

[0016] According to another aspect of this application, a verification device for switching between winter and summer time is also provided, wherein the device includes: One or more processors; Computer-readable medium for storing one or more computer-readable instructions. When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors implement the verification method for switching between day and night time as described above.

[0017] Compared with existing technologies, this application loads a binary format Daylight Saving Time (DST) rule file corresponding to the target time zone of the current region during the device startup phase or when the user actively modifies the system time zone configuration. The DST rule file is then parsed and effectively filtered sequentially to obtain all valid DST switching events and their event entries within a preset future time period. The device is currently offline. When the acquired current system UTC time equals the UTC switching time in the event entry, a time zone switching logic is triggered. After the device's time zone switching operation is completed, the acquired current UTC reference time and the current local time are calculated. The measured offset between local and ground time; when the difference between the measured offset and the expected local offset in the event entry is within a preset tolerance range, the verification status in the event entry is marked as verified, and the valid DST switching event corresponding to the verified event is deleted, and the DST rule file is parsed again; when the difference between the measured offset and the expected local offset in the event entry exceeds the preset tolerance range, the current time zone after the switch, the measured offset, and the system kernel version of the device are added to the event entry, and the updated event entry is written to the abnormal event entry queue. This invention embeds the verification logic, which traditionally relies on external testing tools and manual intervention, into the device's firmware runtime system. It constructs a closed-loop Daylight Saving Time (DST) self-verification mechanism with capabilities such as rule parsing, event pre-simulation, execution monitoring, result comparison, and anomaly response. This mechanism does not rely on network connection or external debugging interface. Even when the device is completely offline, it can still autonomously complete the integrity verification of DST switching behavior, thereby solving the problems of time inconsistency, data distortion, and service interruption caused by the lack of self-checking capabilities in existing technologies. Attached Figure Description

[0018] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A flowchart illustrating a verification method for switching between winter and summer time according to one aspect of this application is shown. Figure 2 This diagram illustrates the core functional units of the firmware runtime architecture of a device to which a verification method for switching between day and winter time according to one aspect of this application is applied. Figure 3 This diagram illustrates the data structure of a prediction table corresponding to a valid DST switching event in a verification method for winter / summer time switching according to one aspect of this application.

[0019] Figure 4 This diagram illustrates the verification process executed by the time verification unit in a verification method for switching between daylight saving time according to one aspect of this application.

[0020] The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0021] The present application will now be described in further detail with reference to the accompanying drawings.

[0022] In a typical configuration of this application, the terminal, the device of the service network, and the trusted party all include one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0023] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0024] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0025] like Figure 1 As shown, Figure 1 This is a flowchart illustrating a verification method for daylight saving time switching, one aspect of this application. This method is applied to the firmware runtime system of a device and is implemented by deploying a complete closed-loop Daylight Saving Time (DST) self-verification mechanism in the device's embedded firmware. The method includes steps S11, S12, S13, S14, and S15, specifically comprising the following steps: Step S11: During the device startup phase or when the user actively modifies the system time zone configuration, load the binary format of the Daylight Saving Time (DST) rule file corresponding to the target time zone of the current region, and parse and effectively filter the DST rule file in sequence to obtain all valid DST switching events and their event entries within a future preset time period; wherein, the device is currently in a network offline state. Step S12: When the current system UTC (Coordinated Universal Time) time obtained is equal to the UTC switching time in the event entry, the time zone switching logic is triggered to perform the operation. Step S13: After the time zone switching operation of the device is completed, calculate the measured offset between the current UTC reference time and the current local time. Step S14: When the difference between the measured offset and the expected local offset in the event entry is within the preset tolerance range, the verification status in the event entry is marked as verified and the valid DST switching event corresponding to the verified is deleted, and the DST rule file is parsed again. Step S15: When the difference between the measured offset and the expected local offset in the event entry exceeds the preset tolerance range, the current time zone after the switch, the measured offset, and the system kernel version of the device are added to the event entry, and the updated event entry is written to the abnormal event entry queue.

[0026] Through steps S11 to S15 above, a closed-loop daylight saving time self-verification mechanism with rule parsing, event pre-simulation, execution monitoring, result comparison and anomaly response capabilities is built in the device's firmware runtime system. This enables the device to autonomously confirm the correctness of its DST switching behavior even without network, debugging interface and human intervention. This mechanism transforms the verification capability that originally belonged to the testing phase into an endogenous function of the product runtime, fundamentally eliminating the time trust blind spot in offline scenarios.

[0027] In this application, the method is applied to the firmware runtime system of the device, which includes eight core functional units, such as... Figure 2 As shown, the modules are: Time Zone Management Module 1, Rule Parsing Unit 2, Prediction Table Generation Module 3, Non-volatile Storage Area 4, System Time Service Module 5, Time Adjustment Unit 6, Time Verification Unit 7, and Anomaly Recording Queue 8. Each of these units is integrated as a software module into the firmware image of the device's main control chip, running in the same operating system kernel space or real-time task scheduler context. Data transfer and state synchronization between them are achieved through memory sharing, function calls, or message queues. Physically, all modules in the device's firmware runtime architecture reside within the same firmware image of the main control chip, directly accessing shared data structures through the kernel address space. Logically, Time Zone Management Module 1 and Rule Parsing Unit 2 form a rule loading chain; Prediction Table Generation Module 3 and Non-volatile Storage Area 4 form a persistent storage chain; System Time Service Module 5, Time Adjustment Unit 6, and Time Verification Unit 7 form a runtime monitoring and verification chain; and Anomaly Recording Queue 8 serves as an independent log channel interfacing with external diagnostic systems. Data flow between modules strictly follows... Figure 2 The flow is as follows: time zone rules flow from time zone management module 1 to rule parsing unit 2; parsing results flow from rule parsing unit 2 to prediction table generation module 3; prediction tables are written from prediction table generation module 3 to non-volatile storage area 4; system time flows from system time service module 5 to time adjustment unit 6 and time verification unit 7; verification results are fed back from time verification unit 7 to prediction table generation module 3 and written to exception record queue 8. The entire process requires no external intervention and does not rely on network connections, achieving end-to-end self-verification of DST switching behavior in offline mode. All interactions are completed through predefined function interfaces or memory-mapped structures, with no external dependencies, ensuring that the end-to-end DST switching self-verification process can still be completed in a completely offline state.

[0028] In the embodiments of this application, during the initial power-on startup phase of the device or after the user modifies the system time zone configuration through the local configuration interface, the time zone management module 1 first loads the DST rule file in binary tzfile format corresponding to the target time zone of the current region where the device is located from the read-only file system path on the device's local machine (e.g., / usr / share / zoneinfo / , etc.). This DST rule file contains the Coordinated Universal Time (UTC) and Daylight Saving Time (DST) conversion rules for the target time zone over historical and future years. The DST rule file is in a standard format conforming to the IANA time zone database specification and contains multiple fields, including key fields such as typecnt (number of time types), timecnt (number of DST switching events), isdst array (indicating whether it is daylight saving time), and gmtoff array (UTC offset in seconds). The time zone management module 1 then reads the entire contents of the DST rule file in binary tzfile format corresponding to the target time zone into a pre-allocated memory buffer and passes the address of this memory buffer as an input parameter to the rule parsing unit 2.

[0029] After loading is complete, the rule parsing unit 2 calls the lightweight rule interpreter built into the firmware to perform structured parsing of the binary DST rule file, extracting nodes of all valid DST switching events in the DST rule file, including the UTC absolute timestamp corresponding to each DST switching event, the local time offset before and after the switching (i.e., UTC+X), and a boolean flag indicating whether daylight saving time is enabled.

[0030] In the embodiments of this application, step S11, which involves sequentially parsing and effectively filtering the DST rule file to obtain all valid DST switching events and their event entries within a future preset time period, specifically includes: Iterate through each DST switching event in the DST rule file and perform structured parsing on each DST switching event to extract the UTC switching time, expected local offset, and boolean flag indicating whether daylight saving time is enabled for each DST switching event. Calculate the time difference between the current system UTC time and the UTC switching time of each DST switching event. If the time difference is within the preset time period in the future, the DST switching event is retained as a valid DST switching event, so as to obtain all valid DST switching events within the preset time period in the future. For each of the valid DST switching events, a corresponding event entry is constructed.

[0031] For example, the rule parsing unit 2 uses a state machine-driven recursive descent parsing algorithm, processing only fields directly related to DST switching. The parsing process is as follows: First, it checks whether the magic number of the header of the binary tzfile format is 0x545A6966 (i.e., "TZif" ASCII code). Then, it skips the device version field and obsolete historical rule segments, and locates the starting position of the current valid rule segment. Next, it reads timecnt (number of switching events) 64-bit signed integer values ​​in sequence to form a UTC switching time list. Then, it reads typecnt (number of time types) 32-bit signed integer values ​​to form a gmtoff offset list. Finally, it reads typecnt single-byte boolean values ​​to form an isdst flag list. The rule parsing unit 2 traverses each DST switching event in each DST rule file according to the timecnt index, extracts the triplet of UTC switching time, expected local offset (corresponding to gmtoff offset) and whether daylight saving time is enabled (isdst flag) corresponding to each DST switching event, forms a structured event sequence for each DST switching event, and passes the structured event sequence of the DST switching event to the prediction table generation module 3 through the function return value.

[0032] After receiving the structured event sequence from the rule parsing unit 2, the prediction table generation module 3 filters out all future preset time periods (in a preferred embodiment of this application, the future preset time period is preferably within the next 12 natural months; of course, the selection of the future preset time period can include, but is not limited to, any future time period such as within a quarter, half a year, a year, or many years), such as valid DST switching events within the next 12 natural months; wherein, the filtering logic is based on the difference between the current system UTC time (provided by the system time service module 5) and the UTC switching time of each DST switching event. If the time difference between the current system UTC time and the UTC switching time of each DST switching event is greater than 0 and less than 31,536,000 seconds (i.e., the number of seconds in the next 12 natural months), then the DST switching event is retained as a valid DST switching event, so as to obtain all valid DST switching events within the next 12 natural months.

[0033] Subsequently, the prediction table generation module 3 constructs a structured prediction table for local DST handover events. This prediction table employs a circular buffer structure, such as... Figure 3The diagram shows the data structure of the prediction table corresponding to all valid DST switching events. This prediction table only retains valid DST switching events within a preset time period (e.g., 12 calendar months) in the future, and constructs a 32-byte record for each valid DST switching event as the event entry for that valid DST switching event. Each event entry contains the following fields: UTC switching time (64-bit integer), expected local offset (32-bit signed integer in seconds), expected daylight saving time status (0 or 1, where 0 represents standard time and 1 represents daylight saving time), and the marked verification status (initially "pending verification"). Further, the event entry for the valid DST handover event is a 32-byte record, wherein the internal fields of the record are arranged with a fixed offset as follows: bytes 0 to 7 represent the UTC handover time, bytes 8 to 11 represent the expected local offset, the high 7 bits of the 12th byte represent the indicator of the expected daylight saving time status (0 or 1), the least significant bit of the 12th byte is used to store and mark the verification status of the valid DST handover event, bytes 13 to 31 are filled with 0 and reserved for expansion space, wherein the initial value of the verification status of the valid DST handover event is used to indicate the identifier to be verified, wherein the initial value of the verification status of the valid DST handover event can preferably be represented as 0.

[0034] Following the above embodiments of this application, after sequentially parsing and effectively filtering the DST rule file to obtain all valid DST switching events and their event entries within a future preset time period, the method further includes: All valid DST switching events and their event entries within the preset time period are arranged in ascending order of time and stored in a circular buffer. The pointer of the circular buffer is used to indicate the current write position and read position, and initially points to the starting address of the circular buffer. The underlying storage driver interface is invoked to write the entire contents of the circular buffer into a preset sector of the non-volatile storage area of ​​the device in the form of key-value pairs, and the write protection flag of the preset sector is set. The non-volatile storage area is the RPMB partition in the SPI NOR Flash or eMMC chip connected to the main control chip of the device. The physical address space of the non-volatile storage area is pre-allocated by the firmware linker script and virtualized through the MMU (Memory Management Unit) kernel address space. The non-volatile storage area only allows atomic write operations through a preset underlying storage driver interface to ensure the integrity and durability of the data in the prediction table formed by all valid DST switching events and their event entries within the preset time period.

[0035] In an embodiment of this application, a prediction table formed by all valid DST switching events and their event entries within the preset time period is written into the non-volatile storage area 4 of the device (e.g., a reserved sector in SPI Flash or an RPMB partition in eMMC) in key-value pairs, and a write protection flag is set to prevent accidental overwriting during runtime.

[0036] Specifically, all valid DST switching events and their entries within the preset time period are sorted in ascending chronological order and stored in a predefined 768-byte circular buffer. This circular buffer consists of 24 consecutive 32-byte slots, corresponding to a maximum of 24 DST switching events (considering a maximum of two switching events per year). A pointer to the circular buffer indicates the current write and read positions, initially pointing to the starting address of the circular buffer. After construction, the prediction table generation module 3 calls the underlying storage driver interface to write the entire contents of the circular buffer as key-value pairs to a preset sector in the non-volatile storage area 4 (e.g., the address range 0x80000–0x802FF of SPI Flash), and sets a write protection flag for this preset sector to prevent accidental overwriting or erasure during runtime.

[0037] Non-volatile storage area 4 is the RPMB (Replay Protected Memory Block) partition in the SPI NOR Flash or eMMC chip connected to the device's main control chip. The RPMB is a special security partition implemented in hardware in storage devices such as embedded multimedia cards (eMMC) and general-purpose flash storage (UFS). Its core design goal is to ensure the security, integrity, and freshness of stored data, primarily resisting replay attacks. Its physical address space is pre-allocated by the firmware linker script and mapped to the kernel virtual address space through the MMU (Memory Management Unit). This area only allows atomic write operations through a dedicated driver interface.

[0038] Following the above embodiments of this application, after sequentially parsing and effectively filtering the DST rule file in step S11 to obtain all valid DST switching events and their event entries within a future preset time period, the method further includes: The system continuously polls the current system UTC time. When the difference between the current system UTC time and the UTC switching time in the event entry is within the first preset time difference, the system enters a high-sensitivity monitoring state and sends an instruction to the system's underlying clock driver to increase the system clock interrupt frequency from 1Hz to 10Hz. At the same time, a high-priority mask flag is registered with the task scheduler to prohibit the execution of all low-priority task scheduling that would cause modification of the system time or cause blocking.

[0039] In the embodiments of this application, the system time service module 5 continuously maintains the system RTC (Real-Time Clock) during normal device operation. Its time base is derived from the hardware RTC chip or the low-power timer within the SoC. The system time service module 5 generates a system clock interrupt at a default frequency of 1Hz, updating the kernel global time variables tv_sec and tv_nsec in each interrupt handler. Simultaneously, the system time service module 5 periodically reads the contents of the prediction table from the non-volatile storage area 4 into a working copy in memory and scans this working copy to find the next nearest DST switching event. During normal operation, the system time service module 5 continuously polls the current system UTC time and calculates the difference between it and the UTC switching time of the next nearest DST switching event in the prediction table. The system time service module 5 traverses all records in the circular buffer, comparing the UTC switching time of each record with the difference between the current system UTC time. When the difference is within the first preset time difference (e.g., 300 seconds, where the first preset time difference can be any time interval), that is, when a record satisfies 0 ≤ (UTC switching time 9 - current system UTC time) ≤ 300 seconds, the system time service module 5 enters a high-sensitivity monitoring state: at this time, it sends an instruction to the underlying clock driver to increase the system clock interrupt frequency from 1Hz to 10Hz to improve time accuracy; at the same time, it registers a high-priority mask flag with the task scheduler to prohibit the execution of all low-priority tasks (such as file system writing, network protocol stack processing, etc.) that may modify the system time or cause long-term blocking, so as to ensure accurate capture and deterministic response of time accuracy near the switching time.

[0040] Continuing with the above embodiments of this application, the step of triggering the time zone switching logic execution operation when the acquired current system UTC time is equal to the UTC switching time in the event entry includes: When the current system UTC time is equal to the UTC switching time in the event entry, read the expected local offset and expected daylight saving time status in the event entry; The kernel time subsystem interface is invoked to update the device's system local time offset to the calculated measured offset; simultaneously, the timestamp conversion tables of all application layer caches are refreshed.

[0041] In the embodiments of this application, when the obtained current system UTC time is exactly equal to the UTC switching time of a certain valid DST switching event in the prediction table (allowing a tolerance of ±1 second, determined by hardware interrupt delay), the system time service module 5 triggers the time adjustment unit 6. The time adjustment unit 6 performs operations according to the time zone switching logic defined in the POSIX.1-2017 standard: First, it reads the expected local offset and the expected daylight saving time status from the event entries of the valid DST switching events; then, it calls the kernel time subsystem interface settimeofday() or clock_settime() to update the system local time offset of the device to the calculated measured offset; at the same time, it refreshes the timestamp conversion tables of all application layer caches (e.g., by broadcasting the SIGALRM signal to notify the relevant processes to call localtime() again), so as to realize the time zone switching of the device.

[0042] After completing the time zone switching operation, the time adjustment unit 6 sends a switching completion signal to the time verification unit 7. Upon receiving the switching completion signal, the time verification unit 7 immediately initiates the verification process, such as... Figure 4 As shown, the time verification unit 7 first calls clock_gettime(CLOCK_REALTIME_COARSE,&ts) to obtain the current UTC reference time, and obtains the representation of the current local time (for example, by back-calculating the local offset through localtime_r(&ts.tv_sec,&tm)). It then calculates the measured offset between the actual observed current local time and the current UTC reference time. The measured offset is calculated by back-calculation: local_offset = ts.tv_sec - mktime(&tm) + tm.tm_gmtoff (where mktime() returns the number of UTC seconds, and tm_gmtoff is the offset field built into the structure). That is, the measured offset is the actual observed local offset, which is recorded as the measured offset acquisition point. Subsequently, the measured offset is compared byte by byte with the expected local offset of the corresponding valid switching event entry in the prediction table. The judgment condition is: |Measured offset - expected local offset| ≤ 1 second. The preset tolerance for comparison is set to ±1 second, that is, the preset tolerance range is within 0 to 1 second, which is used to tolerate the small errors introduced by hardware RTC crystal drift or interrupt delay.

[0043] When the difference between the measured offset and the expected local offset in the event entry is within the preset tolerance range, the verification status in the event entry is marked as verified, for example, the verification status in the event entry is marked as 1. The verification status being marked as 1 indicates that the verification has been passed. The prediction table generation module 3 is notified through the verification result update signal to trigger the prediction table rolling update mechanism: the valid DST switching event corresponding to the verified event is deleted, the rule interpreter in the rule parsing unit 2 is called again to parse the original DST rule file, new DST switching events within the next 12 natural month time window are added to maintain the constant length of the circular buffer, and the updated prediction table is rewritten to the non-volatile storage area 4.

[0044] When the difference between the measured offset and the expected local offset in the event entry exceeds the preset tolerance range, i.e., the difference between the measured offset and the expected local offset exceeds 1 second, the time verification unit 7 will construct a structured exception record. This record contains the following fields: the device's current time zone identifier (such as "Europe / London" or "America / New_York", provided by the time zone management module 1), the event UTC timestamp (i.e., the UTC switching time), the expected local offset, the measured offset, the string of the device's system kernel version (e.g., obtained through the uname() system call), the firmware build hash value (the git commit ID embedded during compilation), etc., to obtain the updated event entry, and append the record of the updated event entry to the exception event entry queue.

[0045] Following the above embodiments of this application, after adding the current time zone after the switch, the measured offset, and the system kernel version of the device to the event entry, and writing the updated event entry into the abnormal event entry queue, the method further includes: The exception event entry queue is a circular buffer of a preset memory in the log partition, which is managed by a FIFO (First In First Out) strategy. When the storage of the circular buffer is full, the earliest record stored in the circular buffer is overwritten. Here, the preset memory can be any size of space, including but not limited to. In a preferred embodiment of this application, the preset memory is preferably 4KB.

[0046] Meanwhile, the time verification unit 7 sets the preset DST fault flag bit in the SoC internal watchdog register (e.g., WDT_REG[7] = 1, etc.), and the preset DST fault flag bit is used to be polled and detected by the power management unit or security monitoring module of the device.

[0047] Continuing with the above embodiments of this application, the method further includes: When the device restores network connectivity, the device's communication module, according to the security policy configuration, reads the updated event entry corresponding to the valid DST switching event that was not uploaded and is used to indicate the abnormal record from the abnormal event entry queue, and uploads it to the manufacturer's diagnostic server corresponding to the device through a TLS (Transport Layer Security) encrypted channel. If the device is still offline, a degraded operating mode is triggered locally by suspending the data acquisition function that relies on precise timestamps, replacing the absolute timestamps with relative time counters, until the DST state is restored to a reliable state.

[0048] In the embodiments of this application, according to the device security policy configuration, it is possible to select that when the device is connected to the network (i.e., when the network connection is restored), the abnormal records (i.e., the updated event entries corresponding to the valid DST switching events used to indicate the abnormal records, which are not uploaded from the abnormal event entry queue) are uploaded to the manufacturer's diagnostic server corresponding to the device through an encrypted channel; or when the device is still offline, a degraded operation mode is triggered locally: suspending the data acquisition function that relies on precise timestamps and replacing the absolute timestamps with a relative time counter until the DST state is restored to reliability. For example, when the device is preferably a health monitoring device, the health monitoring device suspends the timestamp labeling of heart rate data and uses a millisecond counter since startup as the relative time reference; when the device is preferably a security camera, the security camera marks "DST state unreliable" in the video metadata and prompts the user to pay attention to the time continuity on the playback interface; when the device is preferably a pet feeder, the pet feeder switches the timed task from absolute time triggering to relative delay triggering based on the last feeding, etc.

[0049] In the embodiments of this application, to reduce resource overhead, the rule interpreter in rule parsing unit 2 adopts a state machine-driven recursive descent parsing algorithm, implementing only fields directly related to DST switching in the IANA tzfile format (such as isdst, gmtoff, typecnt), ignoring historical obsolete rules and non-switching annotation information. The storage structure of the prediction table in prediction table generation module 3 is optimized for memory alignment, with each entry occupying 32 bytes. The prediction time window of 12 natural months can accommodate a maximum of 24 events (considering a maximum of two switchings per year), with a total occupation of no more than 768 bytes. The comparison logic of time verification unit 7 is executed in a low-priority work queue outside the interrupt context to avoid blocking the system main loop. The code size of the entire self-verification engine is controlled within 8KB, making it suitable for resource-constrained embedded SoC platforms (such as ARM Cortex-M7 or RISC-V RV32IMC architecture).

[0050] Furthermore, the code implementation of the entire self-verification engine has undergone rigorous resource optimization: the parser of rule parsing unit 2 only implements the parsing logic for the four fields typecnt, timecnt, isdst, and gmtoff in the tzfile format, ignoring comments and historical rules other than transitions, ensuring concise parsing logic; the prediction table in prediction table generation module 3 adopts a compact memory layout, with each entry being 32 bytes and 24 entries totaling 768 bytes, adapting to resource-constrained platforms; the comparison logic of time verification unit 7 is not executed in the interrupt context, but is scheduled in a low-priority work queue to avoid affecting the real-time performance of the system's main loop, thereby ensuring the real-time performance of the system's main loop; after static linking of all modules, the total code size is controlled within 8KB, which can be deployed on embedded SoC platforms with ARM Cortex-M7 (with FPU) or RISC-V RV32IMC architecture, with a peak RAM usage of no more than 2KB, meeting the deployment requirements of resource-constrained devices.

[0051] In a preferred embodiment of this application, the device is preferably a smart pet feeder. The following example, using a smart pet feeder deployed in a home environment, further illustrates the specific process of the verification method for switching between day and night time provided in this application. The smart pet feeder uses an ARM Cortex-M7 main control chip, runs a lightweight RTOS system, has a local real-time clock (RTC) module and SPI NOR Flash memory, and is in a state of no network connection for extended periods. After the user first selects the time zone as "America / New_York" through the device's LCD (Liquid Crystal Display) interface, the time zone management module 1 loads the corresponding DST rule file in tzfile format from the read-only file system path / usr / share / zoneinfo / America / New_York built into the firmware. Rule parsing unit 2 then performs structured parsing on the DST rule file, extracting all DST switching events within the next 12 months, including key nodes such as 07:00 UTC on March 9, 2025 (entering daylight saving time, the offset changes from -18000 seconds to -14400 seconds) and 06:00 UTC on November 2, 2025 (exiting daylight saving time, the offset changes from -14400 seconds back to -18000 seconds), and passes these triplet data to prediction table generation module 3.

[0052] The prediction table generation module 3 filters all valid DST switching events based on the current system UTC time (provided by the system time service module 5), constructing a 32-byte record for each valid DST switching event. Bytes 0 to 7 contain the UTC switching time (e.g., 0x67A1B2C0), bytes 8 to 11 contain the expected local offset (e.g., -14400), the high 7 bits of byte 12 contain the expected daylight saving time status 11 (1 indicates daylight saving time), and the lowest bit of byte 12 is initialized to a verification status flag, marked as 0. These 24 records are filled into a circular buffer in chronological order, with the read / write positions maintained by pointers in the circular buffer. The entire record is then written to a pre-allocated Flash sector (addresses 0x80000–0x802FF) in the non-volatile storage area 4, while a write protection bit is set for this Flash sector to prevent overwriting during runtime.

[0053] During normal operation of the smart pet feeder, the system time service module 5 updates the system time at a frequency of 1Hz and periodically loads the prediction table from the non-volatile storage area 4 into the memory working copy. When it detects that the difference between the UTC switching time of a certain record and the current system UTC time falls within a 300-second window (e.g., 06:55 UTC on March 9, 2025), the system time service module 5 immediately increases the system clock interrupt frequency to 10Hz, disables low-priority task scheduling, and enters a high-sensitivity monitoring window. When the current system UTC time precisely reaches the UTC switching time (allowing a hardware tolerance of ±1 second), the system time service module 5 triggers the time adjustment unit 6. The time adjustment unit 6 calls the clock_settime() interface to update the system local offset to -14400 seconds and broadcasts a SIGALRM signal to force a refresh of the application layer time cache.

[0054] After the time zone switching operation is completed, the time verification unit 7 starts the self-verification process: First, it calls clock_gettime(CLOCK_REALTIME_COARSE,&ts) to obtain the current UTC reference time; then it calls localtime_r() to obtain the local time structure tm; then it calculates the measured offset using the formula local_offset = ts.tv_sec - mktime(&tm) + tm.tm_gmtoff as the measured offset acquisition point. The measured offset value is compared with the expected local offset of the corresponding record in the prediction table. If the absolute value of the difference does not exceed 1 second, the preset tolerance interval is determined to be valid. The time verification unit 7 sets the verification status flag of the record to 1 to indicate that it has been verified. It also notifies the prediction table generation module 3 to delete the valid DST switching event corresponding to the verified event through the verification result update signal, re-parses the tzfile file to supplement the DST switching event in March 2026, maintains the constant length of the circular buffer, and writes the updated prediction table back to the non-volatile storage area 4.

[0055] If the measured offset is -14395 seconds (5 seconds deviation) due to firmware bug or severe RTC crystal drift, exceeding the ±1 second tolerance, the preset tolerance range judgment is invalid. The time verification unit 7 constructs an anomaly record, including the time zone identifier "America / New_York", UTC switching time 9 (0x67A1B2C0), expected local offset 10 (-14400), measured offset (-14395), kernel version (such as "Zephyr v3.6.0") and firmware build hash value (such as "a1b2c3d4"), and appends the record to the 4KB circular buffer of the anomaly record queue 8. At the same time, the time verification unit 7 sets the SoC watchdog register WDT_REG[7] = 1 for the power management unit to poll and detect. Since the smart pet feeder is offline, the local security policy automatically activates the downgrade mode: the original feeding instruction set to 08:00 local time every day no longer relies on the absolute timestamp, but is converted to a relative delay trigger based on the last successful feeding time (e.g., every 24 hours ± 10 minutes), thereby avoiding feeding time errors caused by unreliable DST status.

[0056] Following the above embodiments of this application, the parsing of DST rule files can be performed without relying on standard zdump, instead using a pre-built lightweight JSON rule table or summary data delivered from the cloud; the prediction table can be stored using a RAM circular buffer or only cache the next switching event to adapt to devices without Flash write permissions or with limited resources; the self-verification mechanism can be changed to passively listening to time jumps and verifying the offset direction, or comparing based on the relative rate of change rather than the absolute UTC benchmark; exception handling can be extended to automatic rollback, user interaction confirmation, or encrypted reporting to the cloud, making it suitable for various smart terminal devices such as wearables, cameras, and pet collars.

[0057] According to another aspect of this application, a non-volatile storage medium is also provided, on which computer-readable instructions are stored, which, when executed by a processor, cause the processor to implement the verification method for switching between daylight saving time as described above.

[0058] According to another aspect of this application, a verification device for switching between winter and summer time is also provided, wherein the device includes: One or more processors; Computer-readable medium for storing one or more computer-readable instructions. When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors implement the verification method for switching between day and night time as described above.

[0059] For details of the various embodiments of the verification device for switching between winter and summer time, please refer to the corresponding parts of the above-described verification method embodiments for switching between winter and summer time, which will not be repeated here.

[0060] In summary, this application loads a binary format Daylight Saving Time (DST) rule file corresponding to the target time zone of the current region during device startup or when the user actively modifies the system time zone configuration. The DST rule file is then parsed and effectively filtered sequentially to obtain all valid DST switching events and their event entries within a preset future time period. The device is currently offline. When the acquired current system UTC time equals the UTC switching time in the event entry, a time zone switching logic is triggered. After the device's time zone switching operation is completed, the acquired current UTC reference time and current local time are calculated. The measured offset between the two events is used to determine the DST rule file. If the difference between the measured offset and the expected local offset in the event entry is within a preset tolerance range, the verification status in the event entry is marked as verified, and the corresponding valid DST switching event is deleted. The DST rule file is then parsed again. If the difference between the measured offset and the expected local offset in the event entry exceeds the preset tolerance range, the current time zone after the switch, the measured offset, and the system kernel version of the device are added to the event entry, and the updated event entry is written to the abnormal event entry queue. This method embeds the verification logic, which traditionally relies on external testing tools and manual intervention, into the device's firmware runtime system. It constructs a closed-loop DST self-verification mechanism with rule parsing, event pre-simulation, execution monitoring, result comparison, and abnormal response capabilities. This mechanism does not rely on network connection or external debugging interfaces and can autonomously complete the integrity verification of DST switching behavior even when the device is completely offline. This solves the problems of time inconsistencies, data distortion, and service interruptions caused by the lack of self-checking capabilities in existing technologies.

[0061] It should be noted that this application can be implemented in software and / or a combination of software and hardware, for example, using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In one embodiment, the software program of this application can be executed by a processor to implement the steps or functions described above. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, a magnetic or optical drive, a floppy disk, or similar devices. Furthermore, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0062] Furthermore, a portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. The program instructions invoking the methods of this application may be stored in a fixed or removable recording medium, and / or transmitted via data streams in broadcast or other signal carrying media, and / or stored in the working memory of a computer device operating according to the program instructions. Here, one embodiment of this application includes an apparatus comprising a memory for storing computer program instructions and a processor for executing the program instructions, wherein, when the computer program instructions are executed by the processor, the apparatus is triggered to operate the methods and / or technical solutions based on the foregoing embodiments of this application.

[0063] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within this application. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in the apparatus claims may also be implemented by a single unit or device in software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any particular order.

Claims

1. A verification method for switching between winter and summer time, wherein the method is applied to the firmware runtime system of the device, The method includes: During device startup or when the user actively modifies the system time zone configuration, the binary format of the Daylight Saving Time (DST) rule file corresponding to the target time zone of the current region is loaded. The DST rule file is parsed and effectively filtered in sequence to obtain all valid DST switching events and their event entries within a future preset time period; wherein, the device is currently in a network offline state. When the current system UTC time is equal to the UTC switching time in the event entry, the time zone switching logic is triggered to execute the operation. After the time zone switching operation of the device is completed, the measured offset between the current UTC reference time and the current local time is calculated. When the difference between the measured offset and the expected local offset in the event entry is within the preset tolerance range, the verification status in the event entry is marked as verified and the valid DST switching event corresponding to the verified event is deleted, and the DST rule file is parsed again. When the difference between the measured offset and the expected local offset in the event entry exceeds the preset tolerance range, the current time zone after the switch, the measured offset, and the system kernel version of the device are added to the event entry, and the updated event entry is written to the abnormal event entry queue.

2. The method according to claim 1, wherein, The DST rule file is parsed and filtered sequentially to obtain all valid DST switching events and their event entries within a preset future time period, including: Iterate through each DST switching event in the DST rule file and perform structured parsing on each DST switching event to extract the UTC switching time, expected local offset, and boolean flag indicating whether daylight saving time is enabled for each DST switching event. Calculate the time difference between the current system UTC time and the UTC switching time of each DST switching event. If the time difference is within the preset time period in the future, the DST switching event is retained as a valid DST switching event, so as to obtain all valid DST switching events within the preset time period in the future. For each of the valid DST switching events, a corresponding event entry is constructed.

3. The method according to claim 2, wherein, The event entry for the valid DST handover event is a 32-byte record. The internal fields of this record are laid out with a fixed offset as follows: bytes 0 to 7 represent the UTC handover time, bytes 8 to 11 represent the expected local offset, the high 7 bits of the 12th byte represent the expected daylight saving time status, the least significant bit of the 12th byte is used to store and mark the verification status of the valid DST handover event, and bytes 13 to 31 are filled with 0 and reserved for expansion space. The initial value of the verification status of the valid DST handover event is used to indicate the identifier to be verified.

4. The method according to claim 1, wherein, After sequentially parsing and effectively filtering the DST rule file to obtain all valid DST switching events and their event entries within a preset future time period, the method further includes: All valid DST switching events and their event entries within the preset time period are arranged in ascending order of time and stored in a circular buffer. The pointer of the circular buffer is used to indicate the current write position and read position, and initially points to the starting address of the circular buffer. The underlying storage driver interface is invoked to write the entire contents of the circular buffer into a preset sector of the non-volatile storage area of ​​the device in the form of key-value pairs, and the write protection flag of the preset sector is set. The non-volatile storage area is the RPMB partition in the SPI NOR Flash or eMMC chip connected to the main control chip of the device. The physical address space of the non-volatile storage area is pre-allocated by the firmware linker script and mapped to the kernel virtual address space through the memory management unit (MMU). The non-volatile storage area only allows atomic write operations through a preset underlying storage driver interface.

5. The method according to claim 1, wherein, After sequentially parsing and effectively filtering the DST rule file to obtain all valid DST switching events and their event entries within a preset future time period, the method further includes: The system continuously polls the current system UTC time. When the difference between the current system UTC time and the UTC switching time in the event entry is within the first preset time difference, the system enters a high-sensitivity monitoring state and sends an instruction to the system's underlying clock driver to increase the system clock interrupt frequency from 1Hz to 10Hz. At the same time, a high-priority mask flag is registered with the task scheduler to prohibit the execution of all low-priority task scheduling that would cause modification of the system time or cause blocking.

6. The method according to claim 1, wherein, When the acquired current system UTC time equals the UTC switching time in the event entry, the time zone switching logic is triggered to perform the operation, including: When the current system UTC time is equal to the UTC switching time in the event entry, read the expected local offset and expected daylight saving time status in the event entry; The kernel time subsystem interface is invoked to update the device's system local time offset to the calculated measured offset; simultaneously, the timestamp conversion tables of all application layer caches are refreshed.

7. The method according to any one of claims 1 to 6, wherein, After adding the current time zone after the switch, the measured offset, and the system kernel version of the device to the event entry, and writing the updated event entry to the abnormal event entry queue, the method further includes: The exception event entry queue is a pre-reserved circular buffer in the log partition, managed using a FIFO strategy. When the circular buffer is full, the oldest record stored in the circular buffer is overwritten. At the same time, the preset DST fault flag bit in the SoC internal watchdog register is set. The preset DST fault flag bit is used to be polled and detected by the power management unit or security monitoring module of the device.

8. The method according to any one of claims 1 to 6, wherein, The method further includes: When the device restores network connectivity, the device's communication module, according to the security policy configuration, reads the updated event entry corresponding to the valid DST switching event that was not uploaded and is used to indicate the abnormal record from the abnormal event entry queue, and uploads it to the manufacturer's diagnostic server corresponding to the device through a TLS encrypted channel. If the device is still offline, a degraded operating mode is triggered locally by suspending the data acquisition function that relies on precise timestamps, replacing the absolute timestamps with relative time counters, until the DST state is restored to a reliable state.

9. A non-volatile storage medium having stored computer-readable instructions thereon, which, when executed by a processor, cause the processor to perform the method as described in any one of claims 1 to 8.

10. A verification device for switching between winter and summer time, wherein, The device includes: One or more processors; Computer-readable medium for storing one or more computer-readable instructions. When the one or more computer-readable instructions are executed by the one or more processors, the one or more processors perform the method as described in any one of claims 1 to 8.

Images