I have one number that has something related to the currentdate :
634101448539930000
634101448627430000 (this information was took 9 seconds later than the first one)
I have many codes like this and I need to know what those number means. It's something related to the current time, because the new information has always a bigger number than the older ones.
Please if anybody could help me, thanks
It's a Tick Count.
There are 10,000 ticks in 1 ms. That number is the number of milliseconds that have passed since January 1st, 0001 at midnight.
This particular tick count represents the date/time 2010-05-22 17:07:33 (makes sense, since that's today).
Well, the second number is 87500000 greater than the first, and since they're about 9 seconds apart, I'd guess it was number of 100 nanoseconds since some epoch.
If you divide the number by 1x10^7, you get approximately the number of seconds since 1 Jan 0001 (ignoring the calendar reforms and all that stuff).
Dates and times are generally stored as a single number in computer languages. The number usually represents an offset from a specific data. For example it might be an offset from 1 Jan 1970. Usually you don't deal with these numbers. I suspect that if you look at your APIs you will find a function to convert these numbers into more meaningful representations.
It appears that those numbers represent your system's internal system time with precision down to the decimicrosecond (one ten-millionth of a second), as measured from the date January 1st, 1 A.D.
634101448627430000 - 634101448539930000 = 87500000
87500000 / 10,000,000 = 8.75
And, using Perl's Time::Duration module:
&duration_exact(634101448627430000/10_000_000);
2010 years, 263 days, 17 hours, 7 minutes, and 42 seconds
So from that we know that 63410144862 seconds ago was 2010 years ago, so the timestamp is based at the year 1 A.D.
It could be a variation of Unix Time ( a converter for unix time is available here ).
Unix time is a way of representing a date/time as a number that is easy to store and compare. Your numbers may be a substring of unix time, or may be a format designed by the author. I would examine your ASP.NET code to check how it is used, and you'll find out what it means.
Related
Calling an API, I need to specify time in milliseconds. I use DateTime in Python 3 to convert from and to human readable dates and times. But when debugging, I get different results depending on what website I use to convert, so I'm having a hard time debugging when the timestamps are (maybe) wrong. The API doesn't combine time and date in their predicates, but uses milliseconds for both.
Let's look at the date predicate 1656547200000
If I go to https://currentmillis.com it says it's June 30th. All good.
If I go to https://www.epochconverter.com it says it's June 30th. All good.
Let's look at the time predicate from 12600000 to 26700000.
12600000, 26700000
If I go to https://currentmillis.com it says it's UTC (24h) 03:30 - 07:25
If I go to https://www.epochconverter.com it says it's UTC (24h) 20:00 - 00:40
Why that different results?
Historically, UNIX systems reckon time as temporal units (seconds, millis, nanos, etc.) elapsed since an absolute origin instant termed "the Epoch": January 1st, 1970 00:00:00 UTC. This is formally recognized in POSIX.
So "UNIX time" is that system of reckoning, and "Epoch timestamps" are points in time in that system.
Now, you appear to me to be conflating temporal units in your use of Epoch timestamps.
In the case of your "short" timestamp, 12600000 seconds since the Epoch is a different point in time than 12600000 milliseconds since the Epoch. That's why you see them resolve to different times of day, as your converters are interpreting them differently. If you'd included the date in your output, you'd have seen the two points in time are almost six months apart.
I need to save a time interval in a column in a table. based on: http://docs.sqlalchemy.org/en/rel_0_8/core/types.html
I can use Interval type for that. My database is SQLite, and I don't quite understand this description in the document:
"The Interval type deals with datetime.timedelta objects. In PostgreSQL, the
native INTERVAL type is used; for others, the value is stored as a date which
is relative to the “epoch” (Jan. 1, 1970)."
Can anybody tell me how should I do that?
So from what I get in the question, you want to just store an interval and take it out of the database to use it again? But you want to understand how it is stored?
Concerning the storage: This is probably easier with Unix timestamps than with DateTimes. Suppose you want to store timedelta(1), i.e. a delta of one day. What is stored in the database is the time since the "epoch", i.e. second "0" in Unix timestamps and as a date: 1970-01-01 00:00:00 (this is where Unix timestamps start counting the seconds). If you don't know about epoch or timestamp, then read Wikipedia on Unix time.
So we want to store one day of difference? The documentation claims it stored "time since epoch". We just learned "epoch" is "second 0", so a day later would be 60 seconds per minute, 60 minutes per hour, 24 hours per day: 60 * 60 * 24 = 86400. So stored as an integer this is easy to understand: If you find the value 86400 in your database, then it means 1 day, 0 hours, 0 minutes, 0 seconds.
Reality is a bit different: It does not store an integer but a DateTime object. Speaking from this perspective, the epoch is 1970-01-01 00:00:00. So what is a delta of one day since the epoch? That is easy: it's 1970-01-02 00:00:00. You can see, it is a day later.
An hour later? 1970-01-01 01:00:00.
Two days, four hours, 30 seconds?: 1970-01-03 04:00:30.
And you could even do it yourself:
epoch = datetime.utcfromtimestamp(0)
delta = timedelta(1)
one_day = datetime.utcfromtimestamp(86400)
print "Date to be stored in database:", epoch + delta
print "Timedelta from date:", one_day - epoch
As you can see, the calculation is easy and this is all that is done behind the scenes. Take a look at this full example:
interval = IntervalItem(interval=delta)
session.add(interval)
i = session.query(IntervalItem).first()
print "Timedelta from database:", i.interval
You can see it is no different from the above example except it goes through the database. The only thing to keep in mind with this, is this note:
Note that the Interval type does not currently provide date arithmetic operations
on platforms which do not support interval types natively.
That means you should be careful how you use it, for example addition in the query might not be a good idea, but you should just play around with it.
I'm using the following syntax
TIMESTAMPDIFF(2, CHAR(CREATED - TIMESTAMP('1970-01-01 00:00:00'))
where CREATED is of type TIMESTAMP and the database is DB2. The intension is to get the timestamp converted to millis from epoch. If there is a better function that would be more helpful.
Sample data:
For 2011-10-04 13:54:50 returned value is 1316613290 but actual value should be 1317732890 (got from http://www.epochconverter.com)
Query to run
SELECT TIMESTAMPDIFF(2, CHAR(TIMESTAMP('2011-10-04 13:54:50') - TIMESTAMP('1970-01-01 00:00:00'))) FROM SYSIBM.SYSDUMMY1;
This is the result of the fact that TIMESTAMPDIFF returns an estimate of the difference between the timestamps, not the actual value, as expected.
From the reference, page 435 (assuming for iSeries):
The following assumptions are used when converting the element values
to the requested interval type:
One year has 365 days.
One year has 52 weeks.
One year has 12 months.
One quarter has 3 months.
One month has 30 days.
One week has 7 days.
One day has 24 hours.
One hour has 60 minutes.
One minute has 60 seconds.
One second has 1000000 microseconds.
And the actual calculation used is:
seconds + (minutes + (hours + ((days + (months * 30) + (years * 365)) * 24)) * 60) * 60
This is, for obvious reasons, inexact. Not helpful.
This appears to be a direct consequence of the way the timestamp arithmetic results are returned.
That is;
SELECT
TIMESTAMP('1971-03-02 00:00:00') - TIMESTAMP('1970-01-01 00:00:00')
FROM sysibm/sysdummy1
returns:
10,201,000,000.000000
Which can be divided into:
1 year
02 months
01 days
00 hours
00 minutes
00 seconds
000000 microseconds
Which is imprecise period/duration information. While there are a multitude of situations where this type of data is useful, this isn't one of them.
Short answer: The exact answer cannot be correctly calculated in the database, and in fact should not.
Long answer:
The calculations are possible, but rather complex, and definitely not suited for in-database calculation. I'm not going to reproduce them here (look up JodaTime if you're interested, specifically the various Chronology subclasses). Your biggest problem is going to be the fact that months aren't all the same length. Also, you're going to run into major problems if your timestamps are anything other than UTC - more specifically, Daylight Savings time is going to play havoc with the calculation. Why? Because the offsets can change at any time, for any country.
Maybe you could explain why you need the number of milliseconds? Hopefully you're using Java (or able to do so), and can use java.time. But if you're on an iSeries, it's probably RPG...
According to the v9.7 info center, TIMESTAMPDIFF returns an estimated time difference, based on 365 days in a year (not true ~25% of the time), 30 days in a month (not true 75% of the time, though averages out a bit better than that), 24 hours in a day (not true a couple days of the year in some timezones), 60 minutes in an hour (hooray, one right!), and 60 seconds in a minute (true >99.9% of the time - we do get leap seconds).
So, no, this is not the way to get epoch time in DB2. Thus far, I've resorted to getting the time as a timestamp, and converting it in the client.
Part of your error occurs because of the inaccuracy of the TIMESTAMPDIFF function, as others have pointed out.
The other source of error occurs because the Epoch is based on GMT – so you have to take your local timezone into account.
So, you can do this with the following expression:
(DAYS(timestamp('2011-10-04-13.54.50.000000') - current timezone) - DAYS('1970-01-01-00.00.00.000000')) * 86400 + MIDNIGHT_SECONDS(timestamp('2011-10-04-13.54.50.000000') - current timezone)
You can write a simple UDF to simplify this:
create or replace function epoch (in db2ts timestamp)
returns bigint
language sql
deterministic
no external action
return (days(db2ts - current timezone) - days('1970-01-01-00.00.00.000000')) * 86400 + midnight_seconds(db2ts - current timezone);
Good luck,
I exported my Firefox bookmarks, and the 'dateAdded' fields look like this:
1260492675000000
1260492675000000
1266542833000000
They're too big to be a Unix timestamp, and I can't make sense of them. What are they? (I want to convert it into something usable/readable.)
It is PRTime.
This type is a 64-bit integer representing the number of microseconds since the NSPR epoch, midnight (00:00:00) 1 January 1970 Coordinated Universal Time (UTC). A time after the epoch has a positive value, and a time before the epoch has a negative value.
PRTime as described on this page.
You can extract the time using the f3e tool if you can find a link to it.
How to represent the start and end times for one day?
Using October 23, 2008 as an example, is it start 2008-10-23 12:00:00 AM and end 2008-10-23 11:59:59 PM?
I would like to cite a site, http://www.cl.cam.ac.uk/~mgk25/iso-time.html
The international standard notation for the time of day is
hh:mm:ss
where hh is the number of complete hours that have passed since midnight (00-24), mm is the number of complete minutes that have passed since the start of the hour (00-59), and ss is the number of complete seconds since the start of the minute (00-60). If the hour value is 24, then the minute and second values must be zero.
Note: The value 60 for ss might sometimes be needed during an inserted leap second in an atomic time scale like Coordinated Universal Time (UTC). A single leap second 23:59:60 is inserted into the UTC time scale every few years as announced by the International Earth Rotation Service in Paris, to keep UTC from wandering away more than 0.9 s from the less constant astronomical time scale UT1, which is defined by the actual rotation of the earth. In practice you are not very likely to see a clock showing 23:59:60. Most synchronized clocks resynchronize again to UTC some time after a leap second has happened, or they temporarily slow down near the time of a leap seconds, to avoid any disruption that an out-of-range timestamp might otherwise cause.
An example time is
23:59:59
which represents the time one second before midnight.
As with the date notation, the separating colons can also be omitted as in
235959
and the precision can be reduced by omitting the seconds or both the seconds and minutes as in
23:59, 2359, or 23
It is also possible to add fractions of a second after a decimal dot or comma, for instance the time 5.8 ms before midnight can be written as
23:59:59.9942 or 235959.9942
As every day both starts and ends with midnight, the two notations 00:00 and 24:00 are available to distinguish the two midnights that can be associated with one date. This means that the following two notations refer to exactly the same point in time:
1995-02-04 24:00 = 1995-02-05 00:00
In case an unambiguous representation of time is required, 00:00 is usually the preferred notation for midnight and not 24:00. Digital clocks display 00:00 and not 24:00.
ISO 8601 does not specify, whether its notations specify a point in time or a time period. This means for example that ISO 8601 does not define whether 09:00 refers to the exact end of the ninth hour of the day or the period from 09:00 to 09:01 or anything else. The users of the standard must somehow agree on the exact interpretation of the time notation if this should be of any concern.
If a date and a time are displayed on the same line, then always write the date in front of the time. If a date and a time value are stored together in a single data field, then ISO 8601 suggests that they should be separated by a latin capital letter T, as in 19951231T235959.
A remark for readers from the U.S.:
The 24h time notation specified here has already been the de-facto standard all over the world in written language for decades. The only exception are a few English speaking countries, where still notations with hours between 1 and 12 and additions like “a.m.” and “p.m.” are in wide use. The common 24h international standard notation is widely used now even in England (e.g. at airports, cinemas, bus/train timetables, etc.). Most other languages do not even have abbreviations like “a.m.” and “p.m.” and the 12h notation is certainly hardly ever used on Continental Europe to write or display a time. Even in the U.S., the military and computer programmers have been using the 24h notation for a long time.
The old English 12h notation has many disadvantages like:
It is longer than the normal 24h notation.
It takes somewhat more time for humans to compare two times in 12h notation.
It is not clear, how 00:00, 12:00 and 24:00 are represented. Even encyclopedias and style manuals contain contradicting descriptions and a common quick fix seems to be to avoid “12:00 a.m./p.m.” altogether and write “noon”, “midnight”, or “12:01 a.m./p.m.” instead, although the word “midnight” still does not distinguish between 00:00 and 24:00 (midnight at the start or end of a given day).
It makes people often believe that the next day starts at the overflow from “12:59 a.m.” to “1:00 a.m.”, which is a common problem not only when people try to program the timer of VCRs shortly after midnight.
It is not easily comparable with a string compare operation.
It is not immediately clear for the unaware, whether the time between “12:00 a.m./p.m.” and “1:00 a.m./p.m.” starts at 00:00 or at 12:00, i.e. the English 12h notation is more difficult to understand.
Please consider the 12h time to be a relic from the dark ages when Roman numerals were used, the number zero had not yet been invented and analog clocks were the only known form of displaying a time. Please avoid using it today, especially in technical applications! Even in the U.S., the widely respected Chicago Manual of Style now recommends using the international standard time notation in publications.
Surely, if you just want to represent 1 day, you don't need to include the time at all - especially as this raises such a level of discussion about when a day starts or ends. In my experience, date handling is usually complicated enough, without introducing any extra complexity.
Today is Oct 20th 2008 - no more information is necessary.
Or am I missing something?
Oct. 23 starts at 2008-10-23 12AM and finishes at 2008-10-24 12AM—a day ends at the exact same point the next one begins. The very last second begins at 11:59:59 PM but you still have a whole second before the day is over.
Your notation is strange. I'd suggest the standard way of specifying a full day range is:
2008-10-23 00:00:00 and finish 2008-10-23 23:59:59
The definition of the day you mention in the question is any time that is >= 2008-10-23 00:00:00 and < 2008-10-24 00:00:00 .
If you were to use mathematical interval notation, you would write it as
[2008-10-23 00:00:00 , 2008-10-24 00:00:00)
The [ means inclusion, and ) means up to but not including.
In this way you make it easier for users and for yourself.
It depends what you mean by a day. Date handling is, sadly, always more complex than it looks.
To convert your example into 24h ISO date format, you'd say:
2008-10-23 00:00:00 - 2008-10-23 23:59:59
However depending on whether you interpret a range as inclusive or exclusive that could omit the last second of the day*. Programmers normally prefer to keep the upper bound exclusive, so you'd go for:
2008-10-23 00:00:00 - 2008-10-24 00:00:00
Or, as a slightly nicer way of stating the same, if supported (or for human readability):
2008-10-23 00:00:00 - 2008-10-23 24:00:00
*: actually possibly more than one. If the span represents a day in the UTC timezone (or another timezone aligned to it, which is quite likely), there can occasionally be an extra 'leap second' at the end of the day, 23:59:60, in a pointless attempt to keep UTC in line with sidereal time. The next leap second is planned for the end of this year. However, many systems ignore leap seconds because they're silly and annoying.
If you want to represent a 'calendar day' independently of timezones your best bet is the Julian day number. Today is 2454760.