• UTC: The time on the prime meridian is called Universal Coordinated Time. The mismatch of the acronym was caused by the need for its universality for all languages.
• GMT: Previously, Greenwich Mean Time (GMT) was used instead of UTC, since the prime meridian was chosen to pass through the Royal Observatory of Greenwich.
• Other time zones can be written as an offset from UTC. For example, Australian Eastern Standard Time (EST) is written as UTC + 1000, which means that 10:00 UTC is 20:00 EST on the same day.
• Summer time does not affect UTC. This is just a political decision to change the time zone (offset from UTC). For example, GMT is still in use: it is British national time in winter. In the summer, it becomes BST.
• Leap seconds: By international convention, UTC is kept no more than 0.9 seconds from physical reality (UT1, which is measured in solar time) by introducing a "leap second" at the end of the last minute of the year in UTC or the last minute of June.
• Leap seconds are not required to be announced (by astronomers) more than 6 months prior to their introduction. This is a problem if you need any kind of planning with one-second precision for more than 6 months.
• Unix time: Measured by the number of seconds since the “epoch” (early 1970 UTC). Unix time is not affected by time zones or daylight saving time.
• According to the POSIX.1 standard, Unix time is supposed to handle leap seconds by repeating the previous second, for example: 59.00 59.25 59.50 59.75 59.00 ← repeat 59.25 59.50 59.75 00.00 ← increment 00.25 This is a tradeoff: you cannot express any leap second in your system clock and your time is guaranteed to go backwards. On the other hand, every day is exactly 86,400 seconds, and you don't need a table of all past and future leap seconds to convert Unix time into human-readable hours-minutes-seconds.
• It is supposed that ntpd will retry after receiving leap bits from upstream time servers, but I've also seen it do nothing: the system goes one second into the future, then slowly creeps back to the correct time.

What every programmer should know about time

• Time zones refer to presentation level
  Most of your code shouldn't deal with time zones or local time, it should pass Unix time as it is.
• When measuring time, measure Unix time. This is UTC. It's easy to get it (by system functions). It has no time zones or daylight saving time (and leap seconds).
• When you store time, store Unix time. This is one number.
• If you want to keep human readable time (for example, in logs), try to keep it together with Unix time, not instead of.
• When displaying the time, always include the time zone offset. Time format without offset is useless.
• The system clock is not accurate.
• You are online? Every other machine's system clock is not accurate in a different way.
• The system clock can, and will, jump back and forth in time due to things that are beyond your control. Your program must be designed to survive this.
• The ratio of the number of seconds system clock to the quantity real seconds is not accurate and may vary. It mainly depends on the temperature.
• Don't blindly use gettimeofday (). If you want a monotonous (ever-increasing) clock, take a look at clock_gettime (). [Java option: use System.nanoTime () instead of System.currentTimeMillis ()]
• ntpd can change the system time in two ways:
  • Step: the watch jumps forward or backward to the correct time immediately
  • Crank: Change the frequency of the system clock so that it slowly moves towards the correct time.
  Twisting is preferable because it is less damaging, but only useful for correcting small differences.

Special cases

• Time passes at a rate of one second per second for all observers. The frequency of distant clocks in relation to the observer depends on speed and gravity. The clocks inside the GPS satellites are adjusted to overcome the effects of relativity.
• MySQL stores DATETIME columns as number-packed values ​​"YYYYMMDD HHMMSS" If you are concerned about storing timestamps, store them as an integer and use UNIX_TIMESTAMP () and FROM_UNIXTIME () functions to convert.

Because there are no built-in tools in diesel fuel, we create the following script: #! / bin / sh truss date 2> & 1 | grep ^ time | awk "(print $ 3;)" exit $? or nawk "BEGIN (print srand ())" or on perl: perl -e "print time," \ n ";" find out the file modification date: truss -v lstat -t lstat ls -l file.txt 2> & 1 1> / dev / null | grep "mt \ = \" | awk "(print $ 9;)"

How to get Unix time in ...

Perl	time
PHP	time ()
Ruby	Time.now (or Time.new). To output: Time.now.to_i
Python	import time first, then time.time ()
Java	long epoch = System.currentTimeMillis () / 1000;
Microsoft .NET C #	epoch = (DateTime.Now.ToUniversalTime (). Ticks - 621355968000000000) / 10000000;
VBScript / ASP	DateDiff ("s", "01/01/1970 00:00:00", Now ())
Erlang	calendar: datetime_to_gregorian_seconds (calendar: now_to_universal_time (now ())) - 719528 * 24 * 3600.
MySQL	SELECT unix_timestamp (now ())
PostgreSQL	SELECT extract (epoch FROM now ());
SQL Server	SELECT DATEDIFF (s, "1970-01-01 00:00:00", GETUTCDATE ())
JavaScript	Math.round (new Date (). GetTime () / 1000.0) getTime () returns time in milliseconds.
Unix / Linux	date +% s
Other OS	Command line: perl -e "print time" (If Perl is installed on your system)

Converting date to Unix time to ...

PHP	mktime ( watch, minutes, seconds, month, day, year)
Ruby	Time.local ( year, month, day, watch, minutes, seconds, usec) (or Time.gm for GMT / UTC output). To display add .to_i
Python	import time first, then int (time.mktime (time.strptime ("2000-01-01 12:34:00", "% Y-% m-% d% H:% M:% S")))
Java	long epoch = new java.text.SimpleDateFormat ("dd / MM / yyyy HH: mm: ss"). parse ("01/01/1970 01:00:00");
VBScript / ASP	DateDiff ("s", "01/01/1970 00:00:00", date field)
MySQL	SELECT unix_timestamp ( time) Time format: YYYY-MM-DD HH: MM: SS or YYMMDD or YYYYMMDD
PostgreSQL	SELECT extract (epoch FROM date ("2000-01-01 12:34")); With timestamp: SELECT EXTRACT (EPOCH FROM TIMESTAMP WITH TIME ZONE "2001-02-16 20: 38: 40-08"); With an interval: SELECT EXTRACT (EPOCH FROM INTERVAL "5 days 3 hours");
SQL Server	SELECT DATEDIFF (s, "1970-01-01 00:00:00", date field)
Unix / Linux	date +% s -d "Jan 1, 1980 00:00:01"

Converting Unix Time to Human Readable Date ...

PHP	date ( Format, unix time);
Ruby	Time.at ( unix time)
Python	import time first, then time.strftime ("% a,% d% b% Y% H:% M:% S +0000", time.localtime ( unix time)) Replace time.localtime with time.gmtime for GMT date.
Java	String date = new java.text.SimpleDateFormat ("dd / MM / yyyy HH: mm: ss"). Format (new java.util.Date ( unix time*1000));
VBScript / ASP	DateAdd ("s", unix time, "01/01/1970 00:00:00")
PostgreSQL	SELECT TIMESTAMP WITH TIME ZONE "epoch" + unix time* INTERVAL "1 second";
MySQL	from_unixtime ( unix time, optional, output format) Standard output format YYY-MM-DD HH: MM: SS
SQL Server	DATEADD (s, unix time, "1970-01-01 00:00:00")
Microsoft Excel	= (A1 / 86400) + 25569 The result will be in the GMT time zone. For other time zones: = ((A1 +/- time difference for the zone) / 86400) + 25569.
Linux	date -d @ 1190000000
Other OS	Command line: perl -e "print scalar (localtime ( unix time)) "(If Perl is installed) Replace" localtime "with" gmtime "for GMT / UTC time zone.

What is Unix time or Unix epoch (Unix epoch or Unix time or POSIX time or Unix timestamp)?

UNIX-time or POSIX-time (English Unix time) - a way of encoding time, accepted in UNIX and other POSIX-compatible operating systems.
The beginning of the countdown is considered midnight (UTC) from December 31, 1969 to January 1, 1970, the time from that moment is called the "UNIX era" (English Unix Epoch).
UNIX time is consistent with UTC, in particular, when leap seconds are declared UTC, the corresponding second numbers are repeated.
The method of storing time in the form of a number of seconds is very convenient to use when comparing dates (with precision to the second), as well as for storing dates: if necessary, they can be converted to any readable format. Date and time in this format also take up very little space (4 or 8 bytes, depending on the size of the machine word), so it is reasonable to use it for storing large amounts of dates. Performance disadvantages can occur if you access date elements very often, such as the month number, etc. But in most cases, it is more efficient to store time as a single value rather than a set of fields.

Converting the Unix era to a human readable date

Unix start and end date of year, month or day

Converting seconds to days, hours and minutes

How to get Unix time in ...

Perl	time
PHP	time ()
Ruby	Time.now (or Time.new). To output: Time.now.to_i
Python	import time first, then time.time ()
Java	long epoch = System.currentTimeMillis () / 1000;
Microsoft .NET C #	epoch = (DateTime.Now.ToUniversalTime (). Ticks - 621355968000000000) / 10000000;
VBScript / ASP	DateDiff ("s", "01/01/1970 00:00:00", Now ())
Erlang	calendar: datetime_to_gregorian_seconds (calendar: now_to_universal_time (now ())) - 719528 * 24 * 3600.
MySQL	SELECT unix_timestamp (now ())
PostgreSQL	SELECT extract (epoch FROM now ());
SQL Server	SELECT DATEDIFF (s, "1970-01-01 00:00:00", GETUTCDATE ())
JavaScript	Math.round (new Date (). GetTime () / 1000.0) getTime () returns time in milliseconds.
Unix / Linux	date +% s
Other OS	Command line: perl -e "print time" (If Perl is installed on your system)

Converting date to Unix time to ...

PHP	mktime ( watch, minutes, seconds, month, day, year)
Ruby	Time.local ( year, month, day, watch, minutes, seconds, usec) (or Time.gm for GMT / UTC output). To display add .to_i
Python	import time first, then int (time.mktime (time.strptime ("2000-01-01 12:34:00", "% Y-% m-% d% H:% M:% S")))
Java	long epoch = new java.text.SimpleDateFormat ("dd / MM / yyyy HH: mm: ss"). parse ("01/01/1970 01:00:00");
VBScript / ASP	DateDiff ("s", "01/01/1970 00:00:00", date field)
MySQL	SELECT unix_timestamp ( time) Time format: YYYY-MM-DD HH: MM: SS or YYMMDD or YYYYMMDD
PostgreSQL	SELECT extract (epoch FROM date ("2000-01-01 12:34")); With timestamp: SELECT EXTRACT (EPOCH FROM TIMESTAMP WITH TIME ZONE "2001-02-16 20: 38: 40-08"); With an interval: SELECT EXTRACT (EPOCH FROM INTERVAL "5 days 3 hours");
SQL Server	SELECT DATEDIFF (s, "1970-01-01 00:00:00", date field)
Unix / Linux	date +% s -d "Jan 1, 1980 00:00:01"

Converting Unix Time to Human Readable Date ...

PHP	date ( Format, unix time);
Ruby	Time.at ( unix time)
Python	import time first, then time.strftime ("% a,% d% b% Y% H:% M:% S +0000", time.localtime ( unix time)) Replace time.localtime with time.gmtime for GMT date.
Java	String date = new java.text.SimpleDateFormat ("dd / MM / yyyy HH: mm: ss"). Format (new java.util.Date ( unix time*1000));
VBScript / ASP	DateAdd ("s", unix time, "01/01/1970 00:00:00")
PostgreSQL	SELECT TIMESTAMP WITH TIME ZONE "epoch" + unix time* INTERVAL "1 second";
MySQL	from_unixtime ( unix time, optional, output format) Standard output format YYY-MM-DD HH: MM: SS
SQL Server	DATEADD (s, unix time, "1970-01-01 00:00:00")
Microsoft Excel	= (A1 / 86400) + 25569 The result will be in the GMT time zone. For other time zones: = ((A1 +/- time difference for the zone) / 86400) + 25569.
Linux	date -d @ 1190000000
Other OS	Command line: perl -e "print scalar (localtime ( unix time)) "(If Perl is installed) Replace" localtime "with" gmtime "for GMT / UTC time zone.

What is the "Unixtime Converter" tool for?

This tool, first of all, will be useful for webmasters who constantly deal with large amounts of dates or often refer to their elements in their work. Using the "Unixtime Converter" tool, you can easily convert Unix time to a user-friendly date (and vice versa), find out the current Unix epoch time, and get Unix time in different languages programming, DBMS and operating systems.

What is Unix Time?

The Unix era (Unix epoch) began on the night of December 31, 1969 to January 1, 1970. It was this date that was taken as the starting point for "computer" time, which is calculated in seconds and takes up very little disk space - only 4 or 8 bytes. With this coding method, programmers can "hide" any date in one number, and easily convert it back into a format that users understand.

Unix time (also called Unix time or POSIX time) is convenient to use in various operating systems and programming languages, since it is displayed as a single value, and not a certain number of fields that take up space. In addition, UNIX time fully complies with the UTC standard (including in leap years) - in this case, the corresponding seconds are simply repeated.

Unix terminology

A few words about the terms.

So, Unix time(or POSIX time) is the number of seconds that have elapsed since midnight, January 1, 1970, to the present.

Unix Timestamp(timestamp) is a "fixed" time, in other words, a specific date stamped in a number.

UTC(Universal Coordinated Time) is the Coordinated Universal Time, which is "fixed" at the prime meridian, and from which geographic time zones are counted.

How "durable" is the system?

In just a couple of decades, namely on January 19, 2038 at 03:14:08 UTC, Unix time will reach the value 2147483648, and computer systems can interpret this number as negative. The key to solving this problem lies in using a 64-bit (instead of 32-bit) variable to store time. In this case, the stock of numerical values ​​of Unix time will be enough for humanity for another 292 billion years. Not bad, right?

Unix time is one for all

If you live in London or San Francisco, and your friends are in Moscow, then you can "synchronize watches" using Unix time: this system is in this moment time is one for the whole world. Naturally, if the time on the servers is set correctly. And with the tool "Unixtime converter" this conversion will take you a fraction of a second.

This tool is needed to convert a date from the Unix TimeStamp format to a human-readable date and vice versa.

What is Unix time and what is it used for? To understand what this is used for, I'll start with general concept what exactly is Unix time.

Unix time (or TimeStamp, which translated into Russian means "time stamp" and has the same meaning) is the number of seconds since January 1, 1970. That is, the Unix TimeStamp at 01/01/1970 00:00:00 was equal to 0. After 2 minutes (120 seconds), the Unix time was already 120. For example, days later (01/02/1970 00:00:00) Unix time was it is equal to 86400, since 60 * 60 * 24 = 86400 seconds have passed. Now the Unix Time Stamp is already 1566148027 and the number is constantly growing, as the seconds are constantly ticking.

But why use it? The point is that Unix TimeStamp is convenient to use for storing and manipulating dates during programming. I will not go into details, but in short, a number is much more convenient to read and compare than a string with "left" characters. That is why most developers use the Unix TimeStamp to work with the date in their projects, and in the database we often see one very large number in the `date` field, which does not look like a date at all.

This is where this tool comes in handy. With it, you can easily translate this "large number from the database" into a human-readable date. In addition, you can even do the opposite and turn any date into a Unix TimeStamp. These are the possibilities this converter is endowed with.

The year 2038 problem

As I said, the number Unix TimeStamp every second becomes more by 1. Sooner or later, the limit of this number must come and it will be just in 2038. The thing is that the maximum number in 32-bit operating systems widespread at the beginning of the 21st century is 2 31. This is the number that the Unix TimeStamp will reach in 2038.

→ A solution to this problem has already been found. To ensure that in 2038 the sites do not stop correctly counting the time, it is enough to use 64-bit operating system on a hosting / VDS / dedicated server, not 32-bit. With the actively growing capacities of computers and a decrease in their cost, everything goes to the fact that by 2038 the vast majority of services in the field of providing space for the site will be provided on the basis of 64-bit OS. By the way, in a 64-bit system, such a problem will not affect us for at least 292 billion years, which is quite enough to calculate the problem of 2038 solved.

Only for Lifeexample readers it is possible to open an online store on Moguta.CMS with a 15% discount

Unix Time and Unix Timestamp (MySQL, PHP, JavaScript)

Hello, dear blog readers, in this article, I want to tell you about what is Unix time and Unix Timestamp... Programmers often combine these concepts into one, but this is not entirely true. In addition, the article contains many useful notes on the topic of working with Unix Timestamp in PHP, MySQL and JavaScript.

Why Unix Time Starts On Jan 1, 1970

The thing is that Unix time begins counting the Unix era, with the release of the first UNIX systems... The first system of this kind was created in 1969, so the developers took the date from January 1, 1970 at midnight UTC ( UTC).

Let's understand what Unix time and Unix Timestamp are for, and give them clear concepts.

Unix TimestampIs a timestamp that is a sequence of characters representing the number of seconds that have passed since January 1, 1970.

I'll try to give an example to clarify the difference between these two concepts.

At the time of this writing by me, Unix time it was equal 1346765877 .

At the time of reading, by you, this information, a record of the time ( 1346765877 ) is already a label - Unix Timestamp! By converting this timestamp into a readable form, we get the date 09/04/2012 and the time 17:37:57.

Frankly speaking, there is no special sense in separating the two concepts, in my opinion, but it is still useful to have an idea of ​​what constitutes Unix Time and it is also useful to understand that the number of maximum possible seconds since 1970 has a limit!

The end of the Unix era will come in 2038

Fact: maximum binary number on 32 bit systems is the number 01111111 11111111 11111111 11111111 converting it to decimal system, we get the number 2147483647.

January 19, 2038 at 03:14:08 the moment will come when the number of seconds that have passed since the beginning of the Unix era will exceed the maximum available in a 32-bit system, number = 2147483647. If the bit overflows, the date will be reset.

It is very simple to test this theory with an illustrative example:

• Open the standard Windows calculator press ALT + 3, this will convert it to the engineering view;
• Set 4 byte mode, and decimal input type;
• Write the number 2147483647;

• Note the binary representation of the number;
• Add one to the number;

• The addition will result in a negative number!

If we continue to add one, then we get a cyclic closure.

This kind of date ringing will occur from January 19, 2038 on all systems using 32-bit architecture.

In fact, there is no need to be sad, because the developers of computing systems are increasingly introducing 64-bit architectures into widespread use. Let's believe that they will be in time by 2038.

Now let's talk about using unix timestamp in php, mysql and even in javascript.

Working with unix timestamp

A very important point when working with unix timestamp in php or mysql is the need to clearly understand the pros and cons of this date format.

For example, TIMESTAMP cannot be used to specify historical events or events of the distant future. The entire set of dates is limited to the period from 1970 to early 2038. If you set a date beyond 2038, it will not be interpreted correctly by the 32 bit system.

Realizing this limitation, a logical question arises: " Why bother with representing the date in seconds?"

When to use Unix Timestamp

To represent time in our usual system of measuring it, 8 bytes are required, and for unix timestamp it is half as much - 4 bytes.

Saving the amount of data, in my opinion, is the main and indisputable plus in using Unix Time.

In addition, there are a number of useful nuances available when working with UNIX timestamp in mysql... And since all information must be stored on the database server, and it, in turn, has a number of advantages when working with Unix timestamps, the choice towards unix timestamp can be correctly justified by the following provisions.

MySQL provides an appropriate Timestamp data type for working with the unix-time format, setting which we immediately get a useful advantage over the standard formats DATE and DATETIME... The advantage is that by performing the add operation new entry into a table, the column with this data type is filled in automatically. This means that we can save not only on the amount of data, but also on the processor time of the web server.

To reinforce the word with deeds, we will set the following task: when registering a new user in the system, you need to enter the date of his addition to the database.

If the type of the field storing the date in the table is DATETIME, then a request from PHP script will look something like this:

The benefits are obvious!

There is also a minus: if there are several TIMESTAMP fields, only the first is automatically updated.

Does it make sense to use INT instead of timestamp

Many programmers, when working with unix timestamp, use the integer format int (11). This is a completely unreasonable approach to the question, since MySQL provides many useful functions for the timestamp type that affect the speed of working with it. Therefore, by storing the timestamp in INT, we deprive ourselves of all server support for this format. This is roughly the same as storing id in varchar (11) type.

However, there is one excuse for keeping unix timestamp to INT... When transferring a database between different DBMS, a type conflict may arise, i.e. for one of the DBMSs, the timestamp type may be unfamiliar. In this case, using int will take precedence since this format is in all DBMS.

Brief description of MySQL calendar types

TIMESTAMP- data type for storing date and time. The data is stored as the number of seconds since the beginning of the "Unix era". The range of values ​​is 1970-01-01 00:00:00 - 2038-12-31 00:00:00. It takes 4 bytes.

DATE- the data type for storing the date. The range of values ​​is 1000-01-01 through 9999-12-31. It takes 3 bytes.

DATETIME- data type for storing date and time. The range of values ​​is 1000-01-01 00:00:00 - 9999-12-31 00:00:00. It takes 8 bytes and is stored as a number YYYYMMDDHHMMSS./p>

YEAR- data type for storing the year. Values ​​range: 1901 - 2155. It occupies 1 byte.

TIME- data type for storing time. The range is −828: 59: 59 - 828: 59: 59. It takes 3 bytes.

Date translation in unix

It's time to lay out some useful functions for translating the date into unix timestamp and back from unix-time on a readable date.

How to get the current UNIX time

• PHP:

  time ();

• JavaScript:

  Math.round (new Date () .getTime () / 1000.0);

• MySQL:

  SELECT unix_timestamp (now ());