Frage

I'm currently dealing with a system which uses an unknown timestamp mechanism.

The system is running on a Windows machine, so my first thought was that it uses some kind of Windows epoch for its timestamps, but it appears it does not.

My goal is to convert these timestamps to Unix timestamps.


A few examples:

The following timestamp: 2111441659 converts to: 2013-10-01 11:59

  • 2111441998 to 2013-10-01 17:14
  • 2111443876 to 2013-10-02 14:36
  • 2111444089 to 2013-10-02 17:57

(All dates are GMT+2)

I've tried to calculate the reference date using the data above, but somehow I get a different result with every single timestamp.

Could anybody shed some light on this rather odd problem?

Thanks in advance!

War es hilfreich?

Lösung 3

Finally, after many hours of comparing the timestamps with the datetimes, trying to discover the logic between them, I've found the answer by reverse engineering the software which generates the timestamps.

It turns out that the integer timestamps are actually bitwise representations* of the datetimes.

In pseudocode:

year = TimeStamp >> 20;

month = (TimeStamp >> 16) & 15;

day = (TimeStamp >> 11) & 31;

hour = (TimeStamp >> 6) & 31;

minute = TimeStamp & 63;

*I'm not sure if this is the correct term for it, if not, please correct me.

Andere Tipps

To me the number seems to small to be milliseconds. My first guess was then seconds but looking at the speed this number varies with i think minutes is a better guess. Doing some math on it 2111441659/60/24/365 = 4017.20254756 which suggests the epoch might be sometime in the year -2000?

Here is a list of common epochs in computing but the year -2000 is not really there :) How are you obtaining this timestamp?

P.S. are you sure the year is set to 2013 on this machine and not to 4013? :) This would then fit with the .NET epoch of January 1, Year 1

In order to distinguish your timestamp from Unix timestamp, let's call yours The Counter.

So we have four counter values with their corresponding DateTime value. The first thing to do is calculate the counter's unit correspondence to a real time unit, let's say a second.

In order to do that, we need (1) the difference d between two counter values and (2) the difference s between their corresponding DateTimes, in seconds.

Considering the first two values we have d1=2111441998-2111441659=339. The difference between 2013-10-01 11:59 and 2013-10-01 17:14 (in seconds) is s1=18900. Consequently, the counter's unit corresponds to u1=s1/d1=55.7522123894 seconds.

But if we do the same with pairs #2 and #3, we will find that u2=40.9584664536 seconds.

Similarily, pairs #3 and #4 give us u3=56.6197183114 seconds.

My conclusion therefore, is that there's no alignment between the counter values and the corresponding DateTimes provided. That's the reason why you get a different result with each sample.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top