You're confusing multiple concepts. UNIX time is a second counter, that is just a local notion. In the end, someone carried a clock to you and said "according to this nice clock, it's now so and so many seconds since 1.1.1970", and you go "ok, then its now so and so many seconds since 1.1.1970" and continue counting seconds. That's OK for many "household" usages of time keeping, like, say, storing when you last changed your diary document. TAI is also just a second counter, but it's a coordinated one, meaning that it's not just a local counting of time, but the average of many atomic clocks.

UTC is something completely different altogether: It defines what time it is – not just how many seconds since some common event.

"It's fourteen million two hundred thousand twenty six seconds since epoch" is less useful than saying "it's 9:12 in the morning here, and today's the sixth of June", for example, in many cases.

To be clear: "UNIX time" is simply the number of seconds passed since a specific event (0:00 on the first of January 1970). There's no ambiguity there anywhere. If you had a perfect metronome that ticked once per second, and you counted the ticks since that date, that is UNIX time.

It is not based on UTC or anything; it's just a counter of seconds. It does not have to support leap seconds, because these don't exist when you just count seconds. They can exist if you're tasked with the job of defining when "midnight at October the 14th of 2023" is.

Now, your confusion stems from the fact that e.g. 1697300527 (which is the UNIX time a few seconds ago) isn't a very useful time for a human. You will want to convert this second count to a human-readable datetime (e.g., Sat. 14. Oct. 2023 18:22:01).

Time conversions of course have to take leap years, leap seconds, time zones and other corrections into consideration. That means the conversion from UNIX time to a UTC time or any other time representation is not necessarily smooth, continuous, or even unambiguous. (For example: There might be more than one UNIX time stamp that corresponds to 3:15 am on the day that daylight savings time ends in your time zone.)

That's it. While you can always "easily and unambigously" say "it is now so and so many seconds since 1.1.1970", simply by counting the seconds since then (which is what UNIX time is), the conversion to a local time (or coordinated time) representation for human purposes can be non-monotonic.

Anyway, I wanted to ask exactly on how should one convert an integer amount of seconds to exact date in Unix?

By using the timezone information your platform has. Chris Davies proposes to use date, which I agree with. Any reasonable programming language¹ has access to a tzinfo database.

¹ C: ctime(…), C++: std::chrono, Python: python -c 'import datetime;print(datetime.datetime.now())', Perl, Haskell, …)

You're confusing multiple concepts. UNIX time is (from sufficient height) a second counter, that is just a local notion. In the end, someone carried a clock to you and said "according to this nice clock, it's now so and so many seconds since 1.1.1970", and you go "ok, then its now so and so many seconds since 1.1.1970" and continue counting seconds. That's OK for many "household" usages of time keeping, like, say, storing when you last changed your diary document. TAI is also just a second counter, but it's a coordinated one, meaning that it's not just a local counting of time, but the average of many atomic clocks.

UTC is something completely different altogether: It defines what time it is – not just how many seconds since some common event.

"It's fourteen million two hundred thousand twenty six seconds since epoch" is less useful than saying "it's 9:12 in the morning here, and today's the sixth of June", for example, in many cases.

To be clear: "UNIX time" is simply the number of seconds passed since a specific event (Epoch). If you had a perfect metronome that ticked once per second, and you counted the ticks since that date, that is UNIX time. (If it weren't for the fact this counter is actually derived from UTC in a way that effectively moves that Epoch forward a second every time UTC inserts a leap second.)

Now, your confusion stems from the fact that e.g. 1697300527 (which is the UNIX time a few seconds ago) isn't a very useful time for a human. You will want to convert this second count to a human-readable datetime (e.g., Sat. 14. Oct. 2023 18:22:01).

Time conversions of course have to take leap years, leap seconds, time zones and other corrections into consideration. That means the conversion from UNIX time to a UTC time or any other time representation is not necessarily smooth, continuous, or even unambiguous. (For example: There might be more than one UNIX time stamp that corresponds to 3:15 am on the day that daylight savings time ends in your time zone.)

That's it. While you can always "easily and unambigously" say "it is now so and so many seconds since Epoch", simply by counting the seconds since then (which is what UNIX time is), the conversion to a local time (or coordinated time) representation for human purposes can be non-monotonic.

Anyway, I wanted to ask exactly on how should one convert an integer amount of seconds to exact date in Unix?

By using the timezone information your platform has. Chris Davies proposes to use date, which I agree with. Any reasonable programming language¹ has access to a tzinfo database.

¹ C: ctime(…), C++: std::chrono, Python: python -c 'import datetime;print(datetime.datetime.now())', Perl, Haskell, …)

To be clear: "UNIX time" is simply the number of seconds passed since a specific event (0:00 on the first of January 1970). There's no ambiguity there anywhere. If you had a perfect metronome that ticked once per second, and you counted the ticks since that date, that is UNIX time.

It is not based on UTC or anything; it's just a counter of seconds. It does not have to support leap seconds, because these don't exist when you just count seconds. They can exist if you're tasked with the job of defining when "midnight at October the 14th of 2023" is.

Now, your confusion stems from the fact that e.g. 1697300527 (which is the UNIX time a few seconds ago) isn't a very useful time for a human. You will want to convert this second count to a human-readable datetime (e.g., Sat. 14. Oct. 2023 18:22:01).

Time conversions of course have to take leap years, leap seconds, time zones and other corrections into consideration. That means the conversion from UNIX time to a UTC time or any other time representation is not necessarily smooth, continuous, or even unambiguous. (For example: There might be more than one UNIX time stamp that corresponds to 3:15 am on the day that daylight savings time ends in your time zone.)

That's it. While you can always "easily and unambigously" say "it is now so and so many seconds since 1.1.1970", simply by counting the seconds since then (which is what UNIX time is), the conversion to a local time (or coordinated time) representation for human purposes can be non-monotonic.

Anyway, I wanted to ask exactly on how should one convert an integer amount of seconds to exact date in Unix?

By using the timezone information your platform has. Chris Davies proposes to use date, which I agree with. Any reasonable programming language (C, C++, Python, Perl, Haskell, …) has access to a tzinfo database.

You're confusing multiple concepts. UNIX time is a second counter, that is just a local notion. In the end, someone carried a clock to you and said "according to this nice clock, it's now so and so many seconds since 1.1.1970", and you go "ok, then its now so and so many seconds since 1.1.1970" and continue counting seconds. That's OK for many "household" usages of time keeping, like, say, storing when you last changed your diary document. TAI is also just a second counter, but it's a coordinated one, meaning that it's not just a local counting of time, but the average of many atomic clocks.

UTC is something completely different altogether: It defines what time it is – not just how many seconds since some common event.

"It's fourteen million two hundred thousand twenty six seconds since epoch" is less useful than saying "it's 9:12 in the morning here, and today's the sixth of June", for example, in many cases.

To be clear: "UNIX time" is simply the number of seconds passed since a specific event (0:00 on the first of January 1970). There's no ambiguity there anywhere. If you had a perfect metronome that ticked once per second, and you counted the ticks since that date, that is UNIX time.

It is not based on UTC or anything; it's just a counter of seconds. It does not have to support leap seconds, because these don't exist when you just count seconds. They can exist if you're tasked with the job of defining when "midnight at October the 14th of 2023" is.

Now, your confusion stems from the fact that e.g. 1697300527 (which is the UNIX time a few seconds ago) isn't a very useful time for a human. You will want to convert this second count to a human-readable datetime (e.g., Sat. 14. Oct. 2023 18:22:01).

Time conversions of course have to take leap years, leap seconds, time zones and other corrections into consideration. That means the conversion from UNIX time to a UTC time or any other time representation is not necessarily smooth, continuous, or even unambiguous. (For example: There might be more than one UNIX time stamp that corresponds to 3:15 am on the day that daylight savings time ends in your time zone.)

That's it. While you can always "easily and unambigously" say "it is now so and so many seconds since 1.1.1970", simply by counting the seconds since then (which is what UNIX time is), the conversion to a local time (or coordinated time) representation for human purposes can be non-monotonic.

Anyway, I wanted to ask exactly on how should one convert an integer amount of seconds to exact date in Unix?

By using the timezone information your platform has. Chris Davies proposes to use date, which I agree with. Any reasonable programming language¹ has access to a tzinfo database.

¹ C: ctime(…), C++: std::chrono, Python: python -c 'import datetime;print(datetime.datetime.now())', Perl, Haskell, …)