Timestamp updating method of electronic terminal equipment, electronic equipment and program product
By recording the length of the event relative to the boot time after the terminal device is turned on and calculating the real time stamp after the time synchronization, the problem of inaccurate time recording caused by the long-term synchronization of the device after the device is turned on is solved, and the effect of accurately timing after the device is turned on is achieved.
Patent Information
- Application Number
- CN202411928727.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-25
- Publication Date
- 2025-05-02
AI Technical Summary
If the existing terminal equipment does not synchronize for a long time after turning on the computer, the generated time records are inaccurate.
The time stamp is indirectly recorded by recording the length of the event happening relative to the boot time after the device is turned on and before time synchronization. Once the device successfully synchronizes the time, calculate the true timestamp of the event based on the recorded time length and the synchronized real-time time.
It realizes that the timestamp can be accurately recorded after the device is turned on, avoiding the problem of inaccurate time recording caused by long-term unsynchronization, and does not increase hardware costs.
Smart Images

Figure CN119916892A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a timestamp updating method for an electronic terminal device, an electronic device, and a program product. Background Art
[0002] Electronic terminal devices generally need to record the current time during operation, such as mobile phone logs, test records, and production records. These timestamps are essential for data management, problem analysis, and resolution. To ensure the accuracy of time records, the device needs to be synchronized with an external time source through a network or communication interface.
[0003] Currently, most terminal devices rely on the network to obtain and update local time. Although they have timing functions, they usually use the default time when they are turned on, and can only obtain accurate time after synchronization through the network. If the device is not synchronized for a long time, the time record it generates will be inaccurate and lose its reference value.
[0004] To solve the problem of accurate timekeeping when the device is turned on, an alternative solution is to add a clock chip to the device and configure an independent power supply system. This solution synchronizes the real-time time from the factory and continuously supplies power for timekeeping. However, this increases the hardware cost, and if the device is idle for a long time, the independent power supply battery may run out and cause time errors. Summary of the invention
[0005] The purpose of the embodiments of the present application is to provide a timestamp update method, electronic device and program product for an electronic terminal device, so as to solve the problem of inaccurate time records generated when the existing terminal device is not synchronized for a long time after being turned on.
[0006] An embodiment of the present application provides a timestamp updating method for an electronic terminal device, comprising:
[0007] During the offline operation after power-on and before time synchronization, if an event that needs to record a timestamp occurs, the length of time Li from power-on to the event occurrence is saved as the timestamp of the event;
[0008] After the time is successfully synchronized, the current timestamp is updated to the real-time timestamp Tnew, and the time length L0 from power-on to synchronization time is saved;
[0009] According to the time L0 from power-on to synchronization time and the real-time timestamp Tnew, the power-on time T0 is obtained;
[0010] The real timestamp of the event is obtained based on the power-on time and the time length Li from power-on to the occurrence of the event.
[0011] In the above technical solution, during the offline operation of the electronic terminal device after it is turned on and before time synchronization, the timestamp is indirectly recorded by recording the length of the event relative to the time of the power-on. Once the device successfully synchronizes the time, it will calculate the real timestamp of the event based on the recorded time length and the real time after synchronization.
[0012] Specifically, after the device is powered on and in the offline operation process before time synchronization, if an event that needs to record a timestamp occurs, the time length Li from power-on to the occurrence of the event is calculated. This time length Li is saved as the timestamp of the event. The timestamp here is not the direct date and time, but the length relative to the power-on time.
[0013] When the device successfully synchronizes the time, the current timestamp is updated to the real-time timestamp Tnew. At the same time, the time length L0 from power-on to synchronization is saved. This time length is the total time from the device power-on to the successful synchronization time.
[0014] The device power-on time T0 can be inferred from the time length L0 from power-on to synchronization time saved after synchronization, and the real-time timestamp Tnew. Here, L0 and Tnew should be expressed in the same time unit (such as seconds, milliseconds, etc.).
[0015] With the power-on time T0 and the length Li of each event relative to the power-on time, the real timestamp of each event can be calculated.
[0016] Among them, the real timestamp of the event Ti=T0+Li; the boot time T0=Tnew-L0.
[0017] In some optional implementations, when the machine is turned on, the following steps are also included:
[0018] Get the number of power-on times in the memory, add 1 to the number of power-on times, and then update it into the memory.
[0019] In the above technical solution, when the device is turned on, the current number of power-on times is first read from a memory (such as a non-volatile memory). Then, the number of power-on times is increased by 1 to indicate that the device has undergone another power-on process. Finally, the updated number of power-on times is saved back to the memory so that it can continue to be accumulated the next time it is turned on.
[0020] In some optional embodiments, during offline operation after power-on and before time synchronization, if an event occurs that requires a timestamp to be recorded, the length of time Li from power-on to the occurrence of the event is saved as the timestamp of the event, and the current number of power-ons is associated with the event and saved.
[0021] In the above technical solution, after the device is turned on and in the offline operation process before time synchronization, if an event that needs to record a timestamp occurs, the system will perform the following operations: calculate the time length Li from the power-on to the occurrence of the event, and save this time length as the timestamp of the event (relative timestamp). At the same time, the system will obtain the current number of power-on times (the value that has been updated at the time of power-on) and associate this number of power-on times with the event. The associated information (including the relative timestamp Li and the number of power-on times) will be saved in the device's memory for subsequent use or query.
[0022] In some optional implementations, before obtaining the real timestamp of the event according to the power-on time and the time length Li from the power-on to the event occurrence, the method further includes:
[0023] Determine whether the timestamp of the event is less than the set value:
[0024] If yes, the timestamp of the event is determined to be the length of time Li from power-on to the occurrence of the event, and the next step is entered;
[0025] If not, the timestamp of the event is determined to be a real timestamp, and the timestamp of the event is saved.
[0026] In the above technical solution, a judgment step is introduced in the timestamp update method, which is used to verify the validity of the timestamp (relative timestamp) of the event before calculating the real timestamp of the event. Before calculating the real timestamp of the event based on the power-on time and the length of time Li from power-on to the occurrence of the event, the system will first determine whether the timestamp of the event (i.e., the relative timestamp Li) is less than a preset setting value. This setting value can be set according to the specific application scenario and requirements of the device, and is usually a reasonable upper limit of the time range to ensure the validity of the timestamp. For example, the setting value can be the factory date of the electronic terminal device or a larger value. The length of time from the power-on of the electronic terminal device to the occurrence of the event (the event occurs earlier than time synchronization) is less than this larger setting value.
[0027] If the event timestamp is less than the set value, it indicates that the event occurred within a reasonable time range after the device was turned on. Therefore, the event timestamp can be directly determined as the time length Li from the power-on to the event occurrence. Then, the system enters the next step, that is, to calculate the real timestamp of the event based on the power-on time and this time length Li, or to perform the next item about the validity verification of the relative timestamp Li of the event.
[0028] If the event timestamp is not less than the set value, it indicates that the event timestamp has been updated to the real timestamp. For example, if the set value is the production date of the electronic terminal device, the real timestamp of the event must be greater than the production date of the electronic terminal device.
[0029] This embodiment introduces a timestamp validity verification step to avoid the situation where a timestamp that has already been updated is repeatedly updated, resulting in a timestamp error.
[0030] In some optional implementations, before obtaining the real timestamp of the event according to the power-on time and the time length Li from the power-on to the event occurrence, the method further includes:
[0031] Determine whether the number of boot times corresponding to the event is the same as the number of boot times in the memory:
[0032] If yes, go to the next step;
[0033] If not, the timestamp of the event is marked as a pending timestamp.
[0034] In the above technical solution, before calculating the real timestamp of the event, the system will first check whether the number of power-on times associated in the event record matches the number of power-on times currently recorded in the memory (such as non-volatile memory), which is also a validity verification of the relative timestamp Li associated with the event. The purpose of this step is to ensure that the event occurred in the current power-on cycle, rather than in a past power-on cycle.
[0035] If the number of power-on times corresponding to the event is the same as the number of power-on times in the memory, this indicates that the event occurred within the current power-on cycle. Therefore, we can proceed to the next step, which is to calculate the real timestamp of the event based on the power-on time and the length of time Li from power-on to the occurrence of the event, or to perform the next item on the validity verification of the relative timestamp Li of the event.
[0036] If the number of power-on times corresponding to the event is different from the number of power-on times in the memory, it indicates that the event occurred in the previous power-on cycle, but was delayed to the current power-on cycle for some reason. For example, time synchronization was never performed in the previous power-on cycle, and then the electronic terminal device was turned off and then turned on again. The event in the previous power-on cycle was not updated to the real timestamp and may be processed in the current power-on cycle. In this case, the system will mark the timestamp of the event as a pending timestamp and put it into a pending queue for further processing or analysis.
[0037] In some optional implementations, after marking the timestamp of the event as a to-be-processed timestamp, the method further includes:
[0038] Manually assign timestamps to be processed, or discard the data.
[0039] In the above technical solution, for events marked as pending timestamps, the system may provide a user interface (UI) or management interface to allow administrators or users with corresponding permissions to manually assign correct timestamps to these events. Manual assignment may be based on the administrator's understanding of the event context, comparison with other timestamps, analysis of system logs, etc. Through manual assignment, it is possible to ensure that the timestamp of the event is as accurate as possible, thereby maintaining the consistency and integrity of the event record. In some cases, if the events with pending timestamps cannot be accurately assigned a valid timestamp, or these events are no longer important to the operation of the system or data analysis, the system may choose to discard these data. Before discarding the data, the system may generate a log or report to record the relevant information of the discarded events for future auditing or analysis.
[0040] In some optional implementations, before obtaining the real timestamp of the event according to the power-on time and the time length Li from the power-on to the event occurrence, the method further includes:
[0041] Determine whether the timestamp of the event is less than the time length L0 from boot to synchronization time:
[0042] If yes, go to the next step;
[0043] If not, the timestamp of the event is marked as a pending timestamp.
[0044] In the above technical solution, a judgment step is introduced in the timestamp update method, which is used to verify the validity of the timestamp (relative timestamp) of the event before calculating the real timestamp of the event. Before calculating the real timestamp of the event based on the power-on time and the length of time Li from the power-on to the event occurrence, the system will first determine whether the timestamp of the event (i.e., the relative timestamp Li) is less than the length of time L0 from the power-on to the synchronization time. Because the event occurs between the power-on time and the synchronization time, the relative timestamp Li of the event should be less than the length of time L0 from the power-on time to the synchronization time.
[0045] If the relative timestamp Li of the event is greater than or equal to the length of time L0 from the power-on time to the synchronization time, it indicates that this record is not the record generated by this power-on time. Because the variable size has an upper limit at the software level, it will be cleared and re-recorded after reaching the upper limit, which may cause the relative timestamp Li of the recorded event to be greater than or equal to the length of time L0 from the power-on time to the synchronization time.
[0046] An electronic device provided in an embodiment of the present application includes: a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the machine-readable instructions are executed by the processor, any of the above methods is performed.
[0047] A computer program product provided in an embodiment of the present application includes a computer program / instruction, which implements the steps of any of the above methods when executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS
[0048] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.
[0049] Figure 1 A flowchart of a method for updating a timestamp of an electronic terminal device provided in an embodiment of the present application;
[0050] Figure 2 A flowchart of updating timestamp of an electronic terminal device provided in an embodiment of the present application;
[0051] Figure 3 A possible structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0052] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.
[0053] Please refer to Figure 1 , Figure 1 A flowchart of a method for updating a timestamp of an electronic terminal device provided in an embodiment of the present application includes:
[0054] Step 100: During the offline operation after power-on and before time synchronization, if an event requiring a timestamp is recorded occurs, the time length Li from power-on to the occurrence of the event is saved as the timestamp of the event;
[0055] Step 200: After the time is successfully synchronized, the current timestamp is updated to the real-time timestamp Tnew, and the time length L0 from the power-on to the synchronization time is saved;
[0056] Step 300, obtaining the power-on time T0 according to the time L0 from power-on to synchronization time and the real-time timestamp Tnew;
[0057] Step 400: Get the real timestamp of the event according to the power-on time and the time length Li from the power-on to the event occurrence.
[0058] In the above technical solution, during the offline operation of the electronic terminal device after it is turned on and before time synchronization, the timestamp is indirectly recorded by recording the length of the event relative to the time of the power-on. Once the device successfully synchronizes the time, it will calculate the real timestamp of the event based on the recorded time length and the real time after synchronization.
[0059] Specifically, after the device is powered on and in the offline operation process before time synchronization, if an event that needs to record a timestamp occurs, the time length Li from power-on to the occurrence of the event is calculated. This time length Li is saved as the timestamp of the event. The timestamp here is not the direct date and time, but the length relative to the power-on time.
[0060] When the device successfully synchronizes the time, the current timestamp is updated to the real-time timestamp Tnew. At the same time, the time length L0 from power-on to synchronization is saved. This time length is the total time from the device power-on to the successful synchronization time.
[0061] The device power-on time T0 can be inferred from the time length L0 from power-on to synchronization time saved after synchronization, and the real-time timestamp Tnew. Here, L0 and Tnew should be expressed in the same time unit (such as seconds, milliseconds, etc.).
[0062] With the power-on time T0 and the length Li of each event relative to the power-on time, the real timestamp of each event can be calculated.
[0063] Among them, the real timestamp of the event Ti=T0+Li; the boot time T0=Tnew-L0.
[0064] In some optional implementations, when starting up, the method further includes: obtaining the number of startup times in the memory, and adding 1 to the number of startup times and updating the result in the memory.
[0065] In the above technical solution, when the device is turned on, the current number of power-on times is first read from a memory (such as a non-volatile memory). Then, the number of power-on times is increased by 1 to indicate that the device has undergone another power-on process. Finally, the updated number of power-on times is saved back to the memory so that it can continue to be accumulated the next time it is turned on.
[0066] In some optional embodiments, during offline operation after power-on and before time synchronization, if an event occurs that requires a timestamp to be recorded, the length of time Li from power-on to the occurrence of the event is saved as the timestamp of the event, and the current number of power-ons is associated with the event and saved.
[0067] In the above technical solution, after the device is turned on and in the offline operation process before time synchronization, if an event that needs to record a timestamp occurs, the system will perform the following operations: calculate the time length Li from the power-on to the occurrence of the event, and save this time length as the timestamp of the event (relative timestamp). At the same time, the system will obtain the current number of power-on times (the value that has been updated at the time of power-on) and associate this number of power-on times with the event. The associated information (including the relative timestamp Li and the number of power-on times) will be saved in the device's memory for subsequent use or query.
[0068] In some optional implementations, before obtaining the real timestamp of the event according to the power-on time and the time length Li from the power-on to the event occurrence, the method further includes:
[0069] Determine whether the timestamp of the event is less than the set value:
[0070] If yes, the timestamp of the event is determined to be the length of time Li from power-on to the occurrence of the event, and the next step is entered;
[0071] If not, the timestamp of the event is determined to be a real timestamp, and the timestamp of the event is saved.
[0072] In the above technical solution, a judgment step is introduced in the timestamp update method, which is used to verify the validity of the timestamp (relative timestamp) of the event before calculating the real timestamp of the event. Before calculating the real timestamp of the event based on the power-on time and the length of time Li from power-on to the occurrence of the event, the system will first determine whether the timestamp of the event (i.e., the relative timestamp Li) is less than a preset setting value. This setting value can be set according to the specific application scenario and requirements of the device, and is usually a reasonable upper limit of the time range to ensure the validity of the timestamp. For example, the setting value can be the factory date of the electronic terminal device or a larger value. The length of time from the power-on of the electronic terminal device to the occurrence of the event (the event occurs earlier than time synchronization) is less than this larger setting value.
[0073] If the event timestamp is less than the set value, it indicates that the event occurred within a reasonable time range after the device was turned on. Therefore, the event timestamp can be directly determined as the time length Li from the power-on to the event occurrence. Then, the system enters the next step, that is, to calculate the real timestamp of the event based on the power-on time and this time length Li, or to perform the next item about the validity verification of the relative timestamp Li of the event.
[0074] If the event timestamp is not less than the set value, it indicates that the event timestamp has been updated to the real timestamp. For example, if the set value is the production date of the electronic terminal device, the real timestamp of the event must be greater than the production date of the electronic terminal device.
[0075] This embodiment introduces a timestamp validity verification step to avoid the situation where a timestamp that has already been updated is repeatedly updated, resulting in a timestamp error.
[0076] In some optional implementations, before obtaining the real timestamp of the event according to the power-on time and the time length Li from the power-on to the event occurrence, the method further includes:
[0077] Determine whether the number of boot times corresponding to the event is the same as the number of boot times in the memory:
[0078] If yes, go to the next step;
[0079] If not, the timestamp of the event is marked as a pending timestamp.
[0080] In the above technical solution, before calculating the real timestamp of the event, the system will first check whether the number of power-on times associated in the event record matches the number of power-on times currently recorded in the memory (such as non-volatile memory), which is also a validity verification of the relative timestamp Li associated with the event. The purpose of this step is to ensure that the event occurred in the current power-on cycle, rather than in a past power-on cycle.
[0081] If the number of power-on times corresponding to the event is the same as the number of power-on times in the memory, this indicates that the event occurred within the current power-on cycle. Therefore, we can proceed to the next step, which is to calculate the real timestamp of the event based on the power-on time and the length of time Li from power-on to the occurrence of the event, or to perform the next item on the validity verification of the relative timestamp Li of the event.
[0082] If the number of power-on times corresponding to the event is different from the number of power-on times in the memory, it indicates that the event occurred in the previous power-on cycle, but was delayed to the current power-on cycle for some reason. For example, time synchronization was never performed in the previous power-on cycle, and then the electronic terminal device was turned off and then turned on again. The event in the previous power-on cycle was not updated to the real timestamp and may be processed in the current power-on cycle. In this case, the system will mark the timestamp of the event as a pending timestamp and put it into a pending queue for further processing or analysis.
[0083] In some optional implementations, after marking the timestamp of the event as a to-be-processed timestamp, the method further includes:
[0084] Manually assign timestamps to be processed, or discard the data.
[0085] In the above technical solution, for events marked as pending timestamps, the system may provide a user interface (UI) or management interface to allow administrators or users with corresponding permissions to manually assign correct timestamps to these events. Manual assignment may be based on the administrator's understanding of the event context, comparison with other timestamps, analysis of system logs, etc. Through manual assignment, it is possible to ensure that the timestamp of the event is as accurate as possible, thereby maintaining the consistency and integrity of the event record. In some cases, if the events with pending timestamps cannot be accurately assigned a valid timestamp, or these events are no longer important to the operation of the system or data analysis, the system may choose to discard these data. Before discarding the data, the system may generate a log or report to record the relevant information of the discarded events for future auditing or analysis.
[0086] In some optional implementations, before obtaining the real timestamp of the event according to the power-on time and the time length Li from the power-on to the event occurrence, the method further includes:
[0087] Determine whether the timestamp of the event is less than the time length L0 from boot to synchronization time:
[0088] If yes, go to the next step;
[0089] If not, the timestamp of the event is marked as a pending timestamp.
[0090] In the above technical solution, a judgment step is introduced in the timestamp update method, which is used to verify the validity of the timestamp (relative timestamp) of the event before calculating the real timestamp of the event. Before calculating the real timestamp of the event based on the power-on time and the length of time Li from the power-on to the event occurrence, the system will first determine whether the timestamp of the event (i.e., the relative timestamp Li) is less than the length of time L0 from the power-on to the synchronization time. Because the event occurs between the power-on time and the synchronization time, the relative timestamp Li of the event should be less than the length of time L0 from the power-on time to the synchronization time.
[0091] If the relative timestamp Li of the event is greater than or equal to the length of time L0 from the power-on time to the synchronization time, it indicates that this record is not the record generated by this power-on time. Because the variable size has an upper limit at the software level, it will be cleared and re-recorded after reaching the upper limit, which may cause the relative timestamp Li of the recorded event to be greater than or equal to the length of time L0 from the power-on time to the synchronization time.
[0092] Please refer to Figure 2 , Figure 2 A flowchart of timestamp update for an electronic terminal device provided in an embodiment of the present application.
[0093] The electronic terminal device of this embodiment has a power-off non-volatile memory (hereinafter referred to as the memory), a timer implemented by software or hardware, which can realize a 1Hz timing function (hereinafter referred to as the 1Hz timer), and can synchronize the latest time from the outside world through wireless or wired communication methods. The following timestamp is a UTC timestamp.
[0094] After the device is powered on, the power-on times variable value in the software system records the power-on times of the system. The device starts from zero when it is powered on for the first time, and automatically increases by one each time it is powered on and saved in the memory. When the device is powered on, there will be a poix_timestamp variable that increases by one per second at a frequency of 1Hz until the latest time is synchronized from the outside world, which is used to record the number of seconds from power-on to synchronization time.
[0095] If a record that needs to be saved is generated during the operation of the device, that is, an event that needs to record a timestamp occurs, the current poix_timestamp variable is saved to the memory as the timestamp of the event when saving the record, and each record will have an associated current boot count saved to the memory. When the current real-time time is input externally (wired, wireless, key input, etc.), the timestamp Tnew of the current real-time time is recorded, and the timestamp T0 of the boot time can be obtained by subtracting the time L0 from the boot time from the obtained real-time timestamp Tnew.
[0096] After successfully inferring the power-on time T0, the offline records before the synchronization time can be reversed. The device reads the records in the memory and first uses a default timestamp as the standard for whether the record has been updated and synchronized. For example, the default timestamp is 2024-11-0100:00:00, and the value of the timestamp at 2024-11-0100:00:00 is 1730390400, so the set value is 1730390400. The timestamp value of the read recorded event is compared with the set value 1730390400. If it is less than 1730390400, it is continued to determine whether the number of power-on times associated with the event is the same as the current number of power-on times of the electronic terminal device. If they are the same, the next step of determination can be continued. Then determine whether the timestamp Li of the event is less than the time L0 from the power-on time to the synchronization time. If Li is less than L0, the real timestamp Ti of the event is calculated as T0+Li.
[0097] This embodiment only needs to implement the time reverse on the software level, and no additional hardware cost is required. The software implementation is not complicated. The core idea of implementing time reverse in this embodiment is to assign a value to the recording timestamp by using a variable poix_timestamp that starts timing when the machine is turned on, so that the device does not have to synchronize the latest time first to ensure the validity of the recorded time. As long as the variable poix_timestamp is available, there is a chance to reverse the correct production time. For a certain event, the time Li from the start of the machine to the occurrence of the event can be obtained through the variable poix_timestamp. The prerequisite for correctly inferring the time is that Li must be smaller than a timestamp of a set default time, such as 2024-11-0100:00:00, which is 1730390400. If it is smaller than this timestamp, it means that this record was generated before the electronic terminal device synchronized the real-time time. Because the value of 1730390400, for the poix_timestamp variable that counts from 0 to 1Hz at startup, is about 54 years, in fact, the electronic terminal device will not experience such a long time without synchronizing the time. At this time, it is determined whether the number of startups associated with the event is consistent with the current number of startups of the electronic terminal device. If it is inconsistent, it means that the electronic terminal device has been shut down and restarted after the record was generated. If the electronic terminal device is shut down and restarted, the previously recorded variable values will be cleared, so there is no way to continue to infer the time, and all data will be invalid. If the number of power-on times associated with the event is consistent with the current number of power-on times of the electronic terminal device, it will also be determined whether the record Li is less than the number of seconds L0 from power-on to synchronization time. If Li is greater than L0, it also means that this record is not the record generated by this power-on. This judgment step and the judgment of whether the power-on times of the event are consistent with the current number of power-on times of the electronic terminal device serve as a double confirmation. Because there is rarely an upper limit on the size of variables at the software level, they will be cleared and re-recorded when the upper limit is reached. In this way, there will be loopholes in judging whether the power-on times of the event are consistent with the current number of power-on times of the electronic terminal device, which is easy to misjudge. When all the above conditions are met, the recorded reverse time can be guaranteed to be accurate.
[0098] Figure 3 A possible structure of an electronic device provided in an embodiment of the present application is shown. Figure 3 The electronic device includes: a processor, a memory and a communication interface. These components are interconnected and communicate with each other through a communication bus and / or other forms of connection mechanisms (not shown).
[0099] The memory includes one or more (only one is shown in the figure), which may be, but not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), etc. The processor and other possible components may access the memory and read and / or write data therein.
[0100] The processor includes one or more (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a microcontroller unit (MCU), a network processor (NP) or other conventional processors; it can also be a special-purpose processor, including a neural network processor (NPU), a graphics processor (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. In addition, when there are multiple processors, some of them can be general-purpose processors and the other part can be special-purpose processors.
[0101] The communication interface includes one or more (only one is shown in the figure), which can be used to communicate directly or indirectly with other devices to exchange data. The communication interface can include an interface for wired and / or wireless communication.
[0102] One or more computer program instructions may be stored in the memory, and the processor may read and execute these computer program instructions to implement the method provided in the embodiment of the present application.
[0103] Understandably, Figure 3 The structure shown is for illustration only. The electronic device may also include Figure 3 More or fewer components as shown, or with Figure 3 Different structures are shown. Figure 3 The components shown in the figure can be implemented by hardware, software or a combination thereof. The electronic device may be a physical device, such as a PC, a laptop, a tablet computer, a mobile phone, a server, an embedded device, etc., or a virtual device, such as a virtual machine, a virtualized container, etc. Moreover, the electronic device is not limited to a single device, but may also be a combination of multiple devices or a cluster consisting of a large number of devices.
[0104] A computer program product provided in an embodiment of the present application includes a computer program / instruction, which implements the steps of any of the above methods when executed by a processor.
[0105] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.
[0106] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0107] Furthermore, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.
[0108] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.
[0109] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims
1. A timestamp updating method for an electronic terminal device, characterized in that: include: During the offline operation after power-on and before time synchronization, if an event that requires a timestamp is recorded occurs, the length of time Li from power-on to the occurrence of the event is saved as the timestamp of the event; After the time is successfully synchronized, the current timestamp is updated to the real-time timestamp Tnew, and the time length L0 from power-on to synchronization time is saved; According to the time L0 from power-on to synchronization time and the real-time timestamp Tnew, the power-on time T0 is obtained; According to the power-on time and the length of time Li from the power-on to the occurrence of the event, the real timestamp of the event is obtained.
2. The method according to claim 1, characterized in that The real timestamp Ti of the event: Ti=T0+Li Among them, the startup time T0 = Tnew-L0.
3. The method according to claim 1, characterized in that At boot time, it also includes: The number of power-on times in the memory is obtained, and the number of power-on times is increased by 1 and then updated into the memory.
4. The method according to claim 3, characterized in that During offline operation after power-on and before time synchronization, if an event that requires a timestamp is occurred, the time length Li from power-on to the occurrence of the event is saved as the timestamp of the event, and the current number of power-ons is associated with the event and saved.
5. The method according to claim 4, characterized in that Before obtaining the real timestamp of the event according to the power-on time and the time length Li from the power-on to the occurrence of the event, the method further includes: Determine whether the timestamp of the event is less than the set value: If yes, then determine that the timestamp of the event is the length of time Li from when the computer is turned on to when the event occurs, and proceed to the next step; If not, it is determined that the timestamp of the event is a real timestamp, and the timestamp of the event is saved.
6. The method according to claim 4, characterized in that Before obtaining the real timestamp of the event according to the power-on time and the time length Li from the power-on to the occurrence of the event, the method further includes: Determine whether the number of startup times corresponding to the event is the same as the number of startup times in the memory: If yes, go to the next step; If not, the timestamp of the event is marked as a pending timestamp.
7. The method according to claim 6, characterized in that After marking the timestamp of the event as a timestamp to be processed, the method further includes: Manually assign a value to the timestamp to be processed, or discard the data.
8. The method according to claim 4, characterized in that Before obtaining the real timestamp of the event according to the power-on time and the time length Li from the power-on to the occurrence of the event, the method further includes: Determine whether the timestamp of the event is less than the time length L0 from the power-on to the synchronization time: If yes, go to the next step; If not, the timestamp of the event is marked as a pending timestamp.
9. An electronic device, characterized in that: include: A processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the machine-readable instructions are executed by the processor, the method according to any one of claims 1 to 8 is performed.
10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the steps of any method described in claims 1-8 are implemented.