data string w timestamp info

The data string appears cut off in the post above.

I will try again

'http//aimtoday.aim.com/today/aimtoday.adp?
product=9&platform=1&channel=360&build=6_5_9
_1&SN=CBOFHLHFFIGCOKCLHKEPCPNDBB&PC=HDL
EDICEBJ&segment=0&UTC=1213642185&LocalTime
=1213624185&nlogin=219&mcAuth=%2FBcAG0hWt
fcAAK8zAcB%2FZkhWtjMIWm7zNSvM2R8AAA%3D%3D

Sorry

Is it possible to make a conditional determination of local time from this information?

A WHAT? 😯 ?
In your case, since
UTC=1213642185
AND
LocalTime =1213624185

It seems to me like improbable that you can squeeze out of it anything but "1213624185".

jaclaz

Here is the text from the report from my tool (the old version is available here, the new version is available to anyone who asks me nicely ) )

Timelord Report - Time Decoder

Input String
String As Entered 1213642185
Interpreted As Text
String As Interpreted 1213642185

Boundary Dates 1900-01-01 to 2101-01-01

Dates Within Boundary
Unix Epoch (sec's) 2008-06-16 184945
Unix Epoch (microsec's) 1970-01-01 002013.642185
Unix Epoch (millisec's) 1970-01-15 010722.185
HFS and HFS+ Time 2039-06-17 184945.0000000

Dates Outside Boundary
Filetime Text 1601-01-01 000201.3642185
Google Chrome Time 1601-01-01 002013.642185

Invalid Times
Filetime (NTFS Time)
Filetime Text (LoHi)
FAT ms + Time + Date
FAT Time + Date
FAT Date Only
IE(FAT) Date + Time
32 bit time_t (Unix Time)
64 bit time_t (Unix Time)
Unix Epoch (days)
HFS and HFS+ Time
Java Time
UUID Time

Paul Tew

writerkeith,

Taking the information in the URL as it is

UTC=1213642185 decodes (Unix) to 06/16/2008 184945 and LocalTime=1213624185 decodes (Unix) to 06/16/2008 134945. That is a difference of five (5) hours (-0500) between UTC and local time. This offset could put you within Eastern Standard Time (EST), however, the month of June would put you in Eastern Daylight Time (EDT) - an offset of four (4) hours (-0400), so the expected local time would be 06/16/2008 144945 EDT.

Some questions to think about

Do the timestamps in the URL have any relation to the the local system clock and time zone settings or are they independent and being derived from the host server?

Do you have any corroborating timestamps from the web-browser history record that this, or a related and/or surrounding, entry may have come from?

This information "is what it is" unless you have any other supporting information to help put it into context.

Regards,

Jesse

Taking the information in the URL as it is
….

Sure ) , but that is also exactly what the originally posted "report" says.

It is the actual question the OP asked that I completely fail to understand.

A Unix GMT of 1213642185 and a Local time of 1213624185 mean that there is a difference of
1213624185-1213642185=-18000 seconds
-18000/3600= -5 hours

Localtime should normally take into account BOTH offset from Greenwich AND current daylight settings.

I mean, supposing that the string comes from a Windows system, since the 1213642185 GMT translates to Mon, 16 Jun 2008 184945 GMT, if the user looked at the lower right corner of the screen while clicking on that link/accessing that site, he/she would have seen 1349, i.e. 5 hours earlier than GMT.
More generally, that click/access happened on that day at 1849 Zulu.

jaclaz

Well, the "report" is a combination of an EnCase extraction of Windows' registry information for the local system's time zone settings - indicating that the system was configured for Eastern Standard Time (-0500) and allowing for Daylight Savings Time (-0400); as well as the URL (which we are to assume was located on the same system).

I take the OP question's to mean that based on the timezone settings for the local system at the time the registry values were extracted and the UTC and local timestamps recorded in URL, can one opine that the the computer that visited the URL was in Eastern Standard Time or Eastern Daylight Time? I would expect the computer to be in Eastern Daylight Time based upon the month in the URL timestamps; again that is why I suggested finding some corroborating information.

I take the OP question's to mean that based on the timezone settings for the local system at the time the registry values were extracted and the UTC and local timestamps recorded in URL, can one opine that the the computer that visited the URL was in Eastern Standard Time or Eastern Daylight Time? I would expect the computer to be in Eastern Daylight Time based upon the month in the URL timestamps; again that is why I suggested finding some corroborating information.

This is where the doubt comes.

A 1213642185 GMT or 1849 Zulu corresponds to 1213624185 with a -5 offset
http//www.epochconverter.com/epoch/timezones.php?epoch=1213642185

Would correspond to either EST or CDT if - as I believe - "localtime" means the actual hour the user can see on a (properly set) clock in the same moment that in Greenwich it is 1849, and he/she would see 1349.

jaclaz

Here is (perhaps) another helpful report from my tool -

Base Time
Time 2008-06-16 184945
TimeZone (UTC) Coordinated Universal Time
Ambiguous? False

Time 1
Time 2008-06-16 134945
TimeZone (UTC-0500) Eastern Time (US & Canada)
Ambiguous? False

Difference to base time 1 hrs 0 mins and 0 secs behind

Time 2
Time 2008-06-16 134945
TimeZone (UTC-0600) Central Time (US & Canada)
Ambiguous? False

Difference to base time Same Time

Difference to Time 1 1 hrs 0 mins and 0 secs ahead

Time 3
Time 2008-06-16 134945
TimeZone (UTC-0600) Guadalajara, Mexico City, Monterrey
Ambiguous? False

Difference to base time Same Time

Difference to Time 1 1 hrs 0 mins and 0 secs ahead

Difference to Time 2 Same Time

Showing that EST with DST applied is not an appropriate Local time but in this example there are two timezones that are (there are in fact, 4 I believe). Of course the computer concerned may not have had DST applied at the time the record was applied (as suggested by the registry information supplied) or the user was in a different time zone or the software concerned didn't care about DST…

Going back to the original question I would say it would be foolhardy to make any assumptions about local time from this one artifact. Try and stand in a court and make a definitive statement without absolute and unequivocal knowledge is foolhardy at best and tantamount to suicidal at worst.

As a writer, I believe I understand an Encase report as part of my story. There is a string of data with a time stamp. It is 1213642185

Have you looked for any client-side code that creates the timestamp? Or have you determined that it indeed is 'local' to the examined computer by some other means?

If it's a timestamp set by the server, it could really be anything, even something that was used a year ago, but now is kept just because it's a pain to change the code, and is just set to whatever the UTC timestamp is set to.

Actually, it doesn't even need to be real – some web creators add 'dummy' or 'canary' parameters with nonsense data just to see if they ever get a response in which the data was altered. If that happens, they can be fairly sure they have a client doing something he shouldn't be doing. In such case, either of the UTC and LocalTime could be a canary.

That is, I think you need to be establish that the data really *is* a timestamp before you try to interpret it. You probably have done so already, and just skipped that part because it isn't really relevant – otherwise a reasonably good to establish it is to list a number of similar requests against a local timestamp, and verify that it changes reasonably in step with local time change.