What timestamp is it?
41056.2752083333 is 14:36 May 27, 2012 GMT+7
41056.2967361111 is 15:07 May 27, 2012 GMT+7
It is from sqlite3 database taken from icq v.7
EDIT
So, thank for the answer.
Here is the func to convert timestamp in icqv7 format to Python's struct_time:
f = lambda x: time.localtime(x*86400-2208988800-172800+3600)
where 2208988800 is the number or seconds between 1 Jan 1900 and 1 Jan 1970,
172800 is the number of seconds in two days,
and 3600 is one hour.
Looks like it's the number of days since the first of January 1900, midnight UTC.
EDIT: Oops - it looks like it's actually two days out, which is very odd. It clearly is a number of days though, as the difference between 41056.2752083333 and 41056.2967361111 is 0.0215277778, which is 31 minutes when taken as "a number of days".
So it looks like you just need to adjust the epoch slightly - with an epoch of December 30th 1899, I get a date/time for the first value of 2012-05-27T06:36:00Z - there's still an hour discrepancy there, but I suspect that may be due to the way you're diagnosing the date/time rather than anything else. Do you have any values in December, for example?
Related
I exported the SQLite db from an iOS app and was wanting to run a query based on the date, but I found that it's in a format I don't recognize. As stated above, the latest value is "623548800". I'm assuming this corresponds to today, since I created a record in the app today. This is 9 digits, so it's too short to be a Unix timestamp, which is 10 digits.
The earliest record in the db is "603244800", which likely corresponds to when I started using the app on 2/13/2020. That's a difference of 20,304,000, so it looks like it's using seconds, as it's been 20,312,837 seconds since then.
Is this essentially tracking seconds based on some proprietary date, or is this a known format?
623548800 - 603244800 = 20304000
20304000/86400 seconds in 24 hours = 235 days
October 5, 2020 - February 13, 2020 = 235 days
UTC Unix timestamp February 13, 2020 = 1581552000
Like the prior comment said it looks like an offset, it might be a timestamp somewhere in source or in db
Your dates are Unix Timestamps.
By using any on line converter (like https://www.epochconverter.com) you can find the dates they correspond to.
The latest value 623548800 corresponds to Thursday, October 5, 1989 12:00:00 AM GMT
and the earliest value 603244800 corresponds to Sunday, February 12, 1989 12:00:00 AM GMT.
So it seems like your dates or off by 31 years.
I found a similar case here: Behind The Scenes: Core Data dates stored with 31 year offset?
If you want you can convert them to the format 'YYYY-MM-DD hh:mm:ss' like this:
UPDATE tablename
SET datecolumn = datetime(datecolumn, 'unixepoch', '+31 year')
or:
UPDATE tablename
SET datecolumn = date(datecolumn, 'unixepoch', '+31 year')
if you are not interested in the time part.
I have to maintain an ASPX page that increments the date/time by passing a value in the querystring in this format:
636529536000000000 in reference to 31 January 2018
636530400000000000 in reference to 01 February 2018
The url format is: /reservas.aspx?t=636530400000000000
What is this date/time format?
It is the number of ticks where a tick is one hundred nanoseconds or one ten-millionth of a second. The number of ticks is measured since the epoch DateTime.MinValue (12:00:00 midnight, January 1, 0001). For example:
new DateTime(636529536000000000).ToString("F", CultureInfo.InvariantCulture)
outputs:
Wednesday, 31 January 2018 00:00:00
Could be a number of days from certain date, similar to julian date calculation:
https://en.wikipedia.org/wiki/Julian_day#Julian_date_calculation
Potentially incorporating the time as well?
Without details of the code I cant really advise from a provided value.
I have a few UNIX timestamps that I've been converting back and forth, and I notice that the last number of the timestamp would change without causing any difference in the date.
For example, if you convert this number to normal date:
1452120848 > 6-1-16 17:54
But if you convert it back:
6-1-16 17:54 > 1452120840
As you can see the last number was changed to a zero. I tried some of the online converters and discovered that the last number could be any number and the date wouldn't change. What does it mean?
The unix time is the time in seconds since 1970.
You don't convert the seconds part of your date, thus it's 'lost' - your numbers may differ by up to 60.
The timestamp of 1452120848 is actually: Wed Jan 6 22:54:08 2016
So you're missing 8 seconds.
The UNIX timestamp gives you the seconds since 1st January 1970 00.00.00 UTC. Since this is seconds and you are just printing up to minutes, the difference is not shown.
However, they are not the same date:
$ date -d#1452120848
Wed Jan 6 23:54:08 CET 2016
$ date -d#1452120840
Wed Jan 6 23:54:00 CET 2016
I'm using SQLite Database Browser to read information from a database containing the browsing history for Google Chrome. My current code that I am executing in the "Execute SQL" panel looks like this:
SELECT last_visit_time,url,title
FROM urls
WHERE url LIKE {PLACEHOLDER} AND title LIKE {PLACEHOLDER}
The stuff on the "WHERE" line is blocked out with {PLACEHOLDER} for privacy purposes. Now, I want to make it such that the data returned in the last_visit_time column is readable instead of a jumbled mess like 13029358986442901. How do I do this and how do I convert Chrome's timestamp to a readable format? How do I get it to order them (the returned rows) by last_visit_time?
The answer is given in this question: "[Google Chrome's] timestamp is formatted as the number of microseconds since January, 1601"
So for example in my sample history database, the query
SELECT
datetime(visit_time / 1000000 + (strftime('%s', '1601-01-01')), 'unixepoch', 'localtime')
FROM visits
ORDER BY visit_time DESC
LIMIT 10;
gives the results:
2014-09-29 14:22:59
2014-09-29 14:21:57
2014-09-29 14:21:53
2014-09-29 14:21:50
2014-09-29 14:21:32
2014-09-29 14:21:31
2014-09-29 14:16:32
2014-09-29 14:16:29
2014-09-29 14:15:05
2014-09-29 14:15:05
Using your timestamp value of 13029358986442901:
SELECT
datetime(13029358986442901 / 1000000 + (strftime('%s', '1601-01-01')), 'unixepoch', 'localtime')
the result is:
2013-11-19 18:23:06
visits.visit_time is in microseconds since January 1, 1601 UTC which is similar but not to be mistaken for Windows filetime which is the number of 100 nanoseconds since January 1, 1601 UTC.
Trivia: Why 1601?
I think the popular answer is because the Gregorian calendar operates on a 400-year cycle, and 1601 is the first year of the cycle that was active at the time Windows NT was being designed. In other words, it was chosen to make the math come out nicely. January 1, 1601 is origin of COBOL integer dates. It is also day 1 by ANSI date format. And if you speculate further according to ISO8601 which is the format in which it is in, ISO8601 works as far back as the year 1581. Prior to 1583 time was based on the proleptic Gregorian calendar which has 366 days per year. Perhaps they just rounded up to the next century.
downloads.start_time is the number of seconds since January 1, 1970 UTC
Trivia: Why 1970?
Well, I'm glad you asked.. It didn't used to be.. Originally it was January 1, 1971 but was later rounded to January 1, 1970. January 1, 1970 is considered to be the birth of UNIX.
It's worth noting that Firefox formats time as the number of microseconds since January 1, 1970 and the name for the format is PRTime
All of these are in an ISO 8601 EPOCH format.
Chromes Timestap is not Unixepoch!!
Chrome's base time is 01/01/1601 00:00:00. To calculate local time, Chrome time has to be converted to seconds by dividing by one-million, and then the seconds differential between 01/01/1601 00:00:00 and 01/01/1970 00:00:00 must be subtracted. There are two ways you can do this, viz SQLite itself and Unix.
SQLITE:
sqlite> SELECT strftime('%s', '1601-01-01 00:00:00');
-11644473600
DATE:
$ date +%s -d 'Jan 1 00:00:00 UTC 1601'
-11644473600
In both commands above, the "%s" represents unixepoch time. The commands calculate the number of seconds between unixepoch time (1970) and the subsequent date (Chrome time base, 1601). Note that the seconds are negative. Of course, this is because you have to count backwards from 1970 to 1601! With this information, we can convert Chrome time in SQLite like this:
sqlite> SELECT datetime((time/1000000)-11644473600, 'unixepoch', 'localtime') AS time FROM table;
Have a good read here.
Here is a compact expression to convert WebKit Time:
sqlite> SELECT datetime(time/1e6-11644473600,'unixepoch','localtime') AS time FROM table;
I'm new to coding so I'm not sure how you do it with sql, however I can show you a method in c#. I am hoping this would help someone.
If the time value given in the database is :
13029358986442901. Select only the first 11 digits 13029358986. You can convert this to time using :
DateTime dateTimeVar = new DateTime(1601,1,1).AddSeconds(time);
The answer here was : 19-11-2013 18:23:06
And this was without your time zone conversion.
You can substract 11644473600000 (1/1/1601 is -11644473600000 in unixepoch) and treat it as a regulat unix epoch timestamp this is assuming miliseconds.
milis: 11644473600000
seconds: 11644473600
my_current_epoch=15684 equivalent time stamp is Thu, 01 Jan 1970 04:21:24
last_password_reset_epoch_time=15547 equivalent time stamp is Thu, 01 Jan 1970 04:19:07
I am not able to understand how difference of these two will give the days since last password reset.
As per my understanding epoch time is denoted in seconds that has elapsed since Jan 1,1970
Can someone please help me understanding this.
man 5 shadow on a Linux box says:
The date of the last password change is given as the number of days since Jan 1, 1970. The password may not
be changed again until the proper number of days have passed, and must be changed after the maximum number
of days. If the minimum number of days required is greater than the maximum number of day allowed, this
password may not be changed by the user.
So, you can find out to within 24 hours when a password was changed by multiplying the value from /etc/shadow by 86400 (the number of seconds in a day — but you didn't need me to tell you that, did you?).
For the values given (bc to the rescue):
15684*86400 = 1355097600
15547*86400 = 1343260800
And:
$ timestamp -u 1355097600 1343260800
1355097600 = Mon Dec 10 00:00:00 2012
1343260800 = Thu Jul 26 00:00:00 2012
$
Timestamp is my program; modern versions of date can handle this too. The -u means 'report in UTC (aka GMT)' rather than in my time zone.
"epoch" value in /etc/shadow = 15684
the seconds in 24 hours (because normally "epoch" value shows in seconds but for some reason (to make compact view, maybe) in /etc/shadow file "epoch" value displays in days, not in seconds) = 24 * 60 * 60 = 86400
And by multipliying these two numbers: 15684 (days) x 86400 (seconds per day); we will get the number 1355097600.
Afterwards, either using Epoch Converter by copy/paste the final result, you can get the date, or
just use date --date #$(( 15684 * 86400 )) command in cli