Learning Unix Time

Here is the Unix clock current time

Online conversion clock

After going through all of the ciferin' below, I figure that Unix is useful for human organization when it is used for smaller measurements of time - probably not larger increments of 4 digits (0000)

To begin learning Unix start with the smaller time frames.

One second is the same in Unix or traditional Standard time. One minute is 60 seconds so 600 seconds is 10 minutes.

The time of this post is 1184700183. If I were to post again tomarrow at the same time of day, the last 5 digits would read 86583 (00183 + 86400)

It might be good to understand where the rollovers from 2 to 3 to 4 to 5 to 6 to 7 digits occurs.
For instance, 2 digits counts up to 99 and becomes 3 digits at 100. 100 seconds is 1min & 40sec.
3 digits can count up to 999. 1000 seconds is a little over 16&1/2m.

3600 is divisible by 4 so 15m is 900 seconds.

The time is now 0183. If I am due to post in 15 minutes then I post at 1083 (0183 + 900 = 1083)

To make it easy, a post could be due in 1000 seconds.

The rollover to 10000 is a bit over 1/8 of a day. 24/8=4. So when the clock rolls over by 5 digits about 4 hours has passed.

You can moniter the time simply by watching one or two of the digit places. Since the last five digits of the time at this moment include zeros (00183) I can easily tell when 86400 seconds have passed.

The rollover into 6 digits represents a week. So 700183 + 604800 = 1304983 a seven digit number. Seven digit numbers rollover with the months.
3000 = 50:00
6000 = 1:40:00
9000 = 2:30:00
30,000 = 8:20:00
60,000 = 16:40:00
90,000 = 25 hours
300,000 = 3 days 9:48:00
600,000 = 6 days 19:36:00
900,000 = 10 days 15:12:00
3,000,000 = 34 days 17:20:00
6,000,000 = 69 days 10:40:00
9,000,000 = 104 days 4 hours
30,000,000 = 347 days 21 h & (Here my brain broke. Can someone calculate this accurately?)

As you can see, some of these numbers relate to eachother nice and roundly and are the most practical to work with.


Here is a simple table of the regular rollovers based on decimal.


1000 = 16:40
10,000 = 2:46:40
100,000 = 27:46:40
1,000,000 = 11 days 13:46:20
10,000,000 = 115 days 15:46:20
100,000,000 = Appr. 3 years & 65days
1,000,000,000 = ??? I think it's about 30 years?

360 = 6:00
3600 = 1 hour (60:00)
36000 = 10 hours
360000 = 100 hours (4 days & 4 hours)
3600000 = 1000 hours (41 days & 16 hours)
36000000 = 10000 hours (416 days & 16 hours)

As we can see, there is great uniformity in Unix because it is all based on units and ten's while standard time is 60 seconds; 60 minutes; 24 hours days; 12 hour days and 12 hour nights (am and pm); 7 days a week; 28, 29, 30 and 31 day months; 365 days a year, 12 months a year and 52 weeks a year.

That is what makes it so hard to transpose Unix.

The reason for these tables is just to get a ballpark idea of what is what.

After we get our thinking into the ballpark we can leave off from this comparison and move on to measurements of natural change with Unix. Then we will be able to make the most practical applications.

Since the basic units in Unix are:

100
1000
10,000
100,000
1,000,000
10,000,000
100,000,000
1,000,000,000

The way to really comprehend Unix is to ask what can be done in the space of each basic division.

100 = 1:40
1000 = 16:40
10,000 = 2:46:40
100,000 = 27:46:40
1,000,000 = 11 days 13:46:20
10,000,000 = 115 days 15:46:20
100,000,000 = Appr. 3 years & 65days
1,000,000,000 = ??? I think it's about 30 years?

50 = 50s
500 = 8:20
5000 = 1:20:20
50,000 = 13:53:20
500,000 = 6 days 1:16:10

60 = 60s
600 = 10:00
6000 = 1:40:00
60,000 = 16:40:00

What natural change can occur or be humanly affected in 100 seconds? In 1000 seconds? In 10,000 second? And so on. You can naturally accomplish more with more time. How long does a thread take to happen? Depends on the type of discussion. A chat can be posted in 100 to 5000 seconds. The drafting of the constitution may require 15,000,000 seconds.

With that level of understanding, we can leave off from Standard time and communicate in Unix.

This is the natural time for an occurance or a change as measured with Unix. Once we are thinking about Unix and Natural time without any reference to Standard Time there will be much less confussion.. Until we get to this point there will be alot of issues about whether it is day or night or what day of the week it is or what month of the year and what year it is.

The time we need be most concerned with is Natural Time as changes that affects the community and the Unix measuremnet of these natural changes.

Think:

"What can I accomplish in 100 seconds?"

"1000 seconds?"

"10,000 seconds?"

If a discussion or a project is going to take 1,000,000 seconds then it doesn't matter if it is night or day in Japan. What matters is the management of those 1,000,000 seconds.

Unix time, or POSIX time, is a system for describing points in time: it is the number of seconds elapsed since midnight UTC of January 1, 1970, not counting leap seconds. It is widely used not only on Unix-like operating systems but in many other computing systems. It is neither a linear representation of time nor a true representation of UTC (though it is frequently mistaken for both) as the times it represents are UTC but it has no way of representing UTC leap seconds (e.g. 1998-12-31 23:59:60).

Modern Unix time is based strictly on UTC. UTC counts time using SI seconds, and breaks up the span of time into days. UTC days are mostly 86400 s long, but are occasionally 86401 s and could be 86399 s long (though the latter option has never been used as of December 2006) in order to keep the days synchronised with the rotation of the Earth (or Universal Time). As is standard with UTC, this article will label days using the Gregorian calendar, and count times within each day in hours, minutes, and seconds. Some of the examples will also show TAI, another time scheme, which uses the same seconds and is displayed in the same format as UTC, but has every day exactly 86400 s long, making no attempt to stay synchronised with the Earth's rotation.

The Unix epoch is the time 00:00:00 UTC on January 1, 1970. There is a problem with this definition, in that UTC did not exist in its current form until 1972; this issue is discussed below. For brevity, the remainder of this section will use ISO 8601 date format, in which the Unix epoch is 1970-01-01T00:00:00Z.

The Unix time number is zero at the Unix epoch, and increases by exactly 86 400 per day since the epoch. Thus 2004-09-16T00:00:00Z, 12 677 days after the epoch, is represented by the Unix time number 12 677 × 86 400 = 1 095 292 800. This can be extended backwards from the epoch too, using negative numbers; thus 1957-10-04T00:00:00Z, 4472 days before the epoch, is represented by the Unix time number -4472 × 86 400 = -386 380 800.

Within each day, the Unix time number is as calculated in the preceding paragraph at midnight UTC (00:00:00Z), and increases by exactly 1 per second since midnight. Thus 2004-09-16T17:55:43.54Z, 64 543.54 s since midnight on the day in the example above, is represented by the Unix time number 1 095 292 800 + 64 543.54 = 1 095 357 343.54. On dates before the epoch the number still increases, thus becoming less negative, as time moves forward.

Unix is similar to Standard time in that it has it's own "B.C." and "A.D." A standard calendar begins at year 1 with the alledged birth of Jesus. With B.C. we count backwards. The standard calendar uses positive and negative numbers. AD represents + and BC represents -.

The Unix epoch begins with 00:00:00 UTC on January 1, 1970. Almost 37 years ago. It may be another 25 or 50 years before it catches on. When people look back at the Unix epoch two thousand years from now it will be interpreted in light of all of the technological changes of the 20th century culminated in the Apollo Moon Landing of July 1969.

Now, in British and American culture it is important to be punctual. To be on time is to be there 5 minutes early. I wonder what would be considered punctual for an e-meeting?

I suppose it could be 1 minute? E-meetings should begin within seconds of their appointed times because people are at their computers.
Or it could be that an e-meeting has a wide range from start to finish. The meeting could begin at 10000 and go until 90000, just spanning about one day. All posts would be due within that time frame. So this gives enough time for those experiencing day and night.

It could also be possible to schedule the posts from what part of the world they originated.

The most important thing is that Unix is the International timekeeping standard.

300 = 5m
600 = 10m
900 = 15m
1000
1200 = 20m
1500 = 25m
1800 = 30m
2000
3600 = 1h
4000
4500 = 1h 15m
5000
9000 = 2h 30m
10000
18000 = 5h
20000
36000 = 10
43200 = 12h
86400 = 24h
90000 = 25h
100000
150000
172800 = 2d
200000
250000
259200 = 3d
260000
300000
345600 = 4d
350000
400000
432000 = 5d
450000
500000
518400 = 6d
604800 = 1w
2419200 = 4w
2500000
31536000 = 1y
315360000 = 10y
3153600000 = 100y

In about 65 years, the clock will ba at about 3 billion.

Read the clock like this:

00 seconds
000 minutes
0000 hours
00000 day portions
000000 days
0000000 weeks
00000000 years
000000000 decades
0000000000 centuries
00000000000 milleniums

Use only the number of digit places that are necessary for the context.

So what are the problems with this kind of timekeeping?


It is going to have the same problems that all of the timekeeping systems have. It is incompatible with any other system. There are no names for the days of the week or months. I can't tell if it's day or night with this system.

But that is exactly the problem that it solves. This system is intended for International communities. The problem with telling the time like this: Wednesday July 18, 2007 9:49 am is that it is not Wedneday everywhere on the planet and it is not morning.

The number of relationships in the above date and the counting systems used are more complex than we realize. Telling time takes years of training in school. 7 days that rollover to one after 7. Each with a different name. Months that rollover without uniform, at 28, 29, 30 or 31 days, depending. 12 months and a rollover into a new year. each month with a different name. Years, decades, centuries and milleniums.

Then we need to consider seconds, minutes and hours. Seconds and minutes rolling over at 60 and hours rolling over at 24!

Then there is am and pm.

Unix eliminates all of that and you just have an accumulation of seconds. The digit places all rollover at 0.

100 = 1:40 (1 & 2/3m)
200 = 3:20
300 = 5:00
400 = 6:40
500 = 8:20
600 = 10:00
900 = 15:00
1000 = 16:40
1200 = 20:00
1500 = 25:00
1800 = 30:00
2000 = 30:20
2500 = 41:40
3000 = 50:00
3600 = 60:00 (1 hour)
4000 = 1:06:40
4500 = 1:15:00
5000 = 1:23:20
9000 = 2:30:00
10000 = 2:46:40
18000 = 5:00:00
20000 = 5:33:20
30000 = 8:16:40
36000 = 10:00:00
40000 = 11:06:40
43200 = 12:00:00
50000 = 15:53:20
60000 = 18:00:00
70000 = 20:46:40
80000 = 23:23:20
86400 = 24:00:00 (1 day)
90000 = 25:00:00
100000 = 27:46:40
150000 = 43:40:00
172800 = 48:00:00 (2 days)
200000 = 55:33:20
250000
259200 = (3 days)
260000
300000
345600 = (4 days)
350000
400000
432000 = (5 days)
450000
500000 = 5days 20:53:00
518400 = (6 days)
604800 = (1 week)
1209600 = (2 weeks)
1814400 = (3 weeks)
2419200 = (4 weeks)
2500000 = (appr. 4 weeks & 1 day)
2592000 = 30 days
31536000 = (1 year)
315360000 = (10 years)
3153600000 = (100 years)

Artimus wrote:
The Unix clock displays the number of seconds elapsed since midnight UTC of January 1, 1970. That is 37 & 1/2 years ago and almost 1.2 billion seconds have elapsed.
I subtract this number with a Unix converter and this is the date I get:

Thu, 16 Jun 1932 00:06:45 UTC

Some group exercises - The 900 second meeting (15 minutes)

The 6000 second meeting (1h 40m)