Time format

[migeo]

I've come across this recently: "0x07e1081b142138002b0000" . This is supposedly a timestamp that I'm required to convert. However I just cannot seem to find what kind of timestamp it is. Definitely not EPOCH, or hex. I'm no longer sure how to interpret it. Thanks

[migeo]

3 minutes ago, Erik Sieghart said:

Do you know how it's being decoded?

I literally have no information at all. It's really frustrating. Just have timestamps like these and I have to convert them. On a side note, nice sora pp.

[zwirek2201]

11 minutes ago, migeo said:

I've come across this recently: "0x07e1081b142138002b0000" . This is supposedly a timestamp that I'm required to convert. However I just cannot seem to find what kind of timestamp it is. Definitely not EPOCK, or hex. I'm no longer sure how to interpret it. Thanks

It looks like it's encoded in some way, if you don't know what kind of encoding this is, it will be quite difficult to decode.

[migeo]

3 minutes ago, zwirek2201 said:

It looks like it's encoded in some way, if you don't know what kind of encoding this is, it will be quite difficult to decode.

lol rip never gonna figure it out like this. Apparently when I asked at work, nobody knows where this comes from. One guy says that it's epock that he was able to convert it to a readable format (the guy who's asking me to do this) but when I asked him how he didn't show me.

[zwirek2201]

Just now, migeo said:

lol rip never gonna figure it out like this. Apparently when I asked at work, nobody knows where this comes from. One guy says that it's epock that he was able to convert it to a readable format (the guy who's asking me to do this) but when I asked him how he didn't show me.

If a guy that was able to solve this is asking you to solve it and gives no support then I think you have a much bigger problem than some time format  I will look through some pages to try to help.

[migeo]

2 minutes ago, zwirek2201 said:

If a guy that was able to solve this is asking you to solve it and gives no support then I think you have a much bigger problem than some time format  I will look through some pages to try to help.

lol thanks

[zwirek2201]

1 minute ago, migeo said:

lol thanks

Where do you live? What kind of application is this and what language is it written in? It may help.

[migeo]

4 minutes ago, zwirek2201 said:

Where do you live? What kind of application is this and what language is it written in? It may help.

This should be a UTC timestamp, as for the language, I'm not sure. That's not my departement. I only take care of selecting stuff from databases and then the logic to transform that stuff in readable data. I thought at first that it's hex but then I noticed that it's too long to be hex. So I'm no longer sure. I'll just ask the guy again how he did it. He told me that excel just transformed it for him but I honestly doubt it. It's tomorrow's problem. But thanks for the help.

[zwirek2201]

Yeah, I though of hex at first, but way too long for that. When you mentioned Excel, I realized that there are indeed some functions such as "Hex2Dec, Hex2Oct, Hex2Bin" ect. maybe they'll help. Good luck!

[Unimportant]

128 bit windows SYSTEMTIME structure decodes as:

0x000000000007e1081b142138002b0000
Do, 05 April 2007 13:32:28

 

That's not to say this is the correct solution as you don't know the encoding, but it's a possibility.

[migeo]

16 hours ago, Unimportant said:

128 bit windows SYSTEMTIME structure decodes as:

0x000000000007e1081b142138002b0000
Do, 05 April 2007 13:32:28

 

That's not to say this is the correct solution as you don't know the encoding, but it's a possibility.

 

15 hours ago, Erik Sieghart said:

That's pretty helpful.

Try it out and see if it maxes sense, OP.

It is indeed helpful. Thanks everybody for trying. Actually have a meeting with the guys in a bit so I'll figure it out by then.

[migeo]

On 8/28/2017 at 7:17 PM, Erik Sieghart said:

That's pretty helpful.

Try it out and see if it maxes sense, OP.

 

On 8/28/2017 at 5:33 PM, zwirek2201 said:

Yeah, I though of hex at first, but way too long for that. When you mentioned Excel, I realized that there are indeed some functions such as "Hex2Dec, Hex2Oct, Hex2Bin" ect. maybe they'll help. Good luck!

 

On 8/28/2017 at 6:01 PM, Unimportant said:

128 bit windows SYSTEMTIME structure decodes as:

0x000000000007e1081b142138002b0000
Do, 05 April 2007 13:32:28

 

That's not to say this is the correct solution as you don't know the encoding, but it's a possibility.

 

 

Firgured it out and forgot to post it here if anybody is interested. This timestamps is established as a RFC 2579 value: For example, today would be: 2017-09-13,13:49:00.0,-5:0 here in canada (year->month->day->hour->minute->seconds->deciseconds(.0 in this example)->direction from UTC (+/-)->hours from UTC(here 4 in Montreal)-> minutes from UTC.

 

 

This is the string that I had, which is already in utc so that's why the last four digits are 0: "0x07e1081b142138002b0000". Furthermore we can see that the string is in hex.

 

The string that we have left to interpret is:  2b

 

Year: 07e1 in hex is 2017 in decimal

Month: 08 (same in hex and dec)

Day: 1B in hex is 27 in dec

Hour: 14 in hex is 20 in dec

Minute: 21 in hex is 33 in dec

Seconds: 38 in hex is 56 in dec

Deciseconds: 00 (pretty straight forward)

Direction from UTC: 2B in hex is 43 in dec which is the ANSI character for +

 

Hope this can be helpful for anybody else.

[zwirek2201]

On 13.09.2017 at 8:05 PM, migeo said:

Firgured it out and forgot to post it here if anybody is interested. This timestamps is established as a RFC 2579 value: For example, today would be: 2017-09-13,13:49:00.0,-5:0 here in canada (year->month->day->hour->minute->seconds->deciseconds(.0 in this example)->direction from UTC (+/-)->hours from UTC(here 4 in Montreal)-> minutes from UTC.

 

 

This is the string that I had, which is already in utc so that's why the last four digits are 0: "0x07e1081b142138002b0000". Furthermore we can see that the string is in hex.

 

The string that we have left to interpret is:  2b

 

Year: 07e1 in hex is 2017 in decimal

Month: 08 (same in hex and dec)

Day: 1B in hex is 27 in dec

Hour: 14 in hex is 20 in dec

Minute: 21 in hex is 33 in dec

Seconds: 38 in hex is 56 in dec

Deciseconds: 00 (pretty straight forward)

Direction from UTC: 2B in hex is 43 in dec which is the ANSI character for +

 

Hope this can be helpful for anybody else.

Nice that you figured that out. Is there a particular reason why they used that kind of approach? It seems like a bit of a hassle to format a date this way.

[migeo]

7 hours ago, zwirek2201 said:

Nice that you figured that out. Is there a particular reason why they used that kind of approach? It seems like a bit of a hassle to format a date this way.

I honestly don't know. We get this polling data from another company. They really made it much more complicated than it needed to be. Why couldn't it have been in EPOCH format.

[DXMember]

3 hours ago, migeo said:

I honestly don't know. We get this polling data from another company. They really made it much more complicated than it needed to be. Why couldn't it have been in EPOCH format.

Why couldn't it just be a GMT time in as by NIST specification in format: CCYYMMDDHHMMSSZ

[migeo]

1 hour ago, DXMember said:

Why couldn't it just be a GMT time in as by NIST specification in format: CCYYMMDDHHMMSSZ

it doesn't really matter which format it is. It's just that they didn't say anything, give us any clue on how to interpret this format. The thing is, if it were epoch, it would be easy to interpret since it's obvious from the get go