8 ms·
This guy is confusing Unix time with local time. This statement: > Unix time is the number of seconds since 1 January 1970 00:00:00 UTC Is true regardless of
by tus87 7y ago
This guy is confusing Unix time with local time. This statement:
> Unix time is the number of seconds since 1 January 1970 00:00:00 UTC
Is true regardless of the calender or leap seconds. Think of seconds in terms of some physical phenomena, like how many times a certain atom trapped in a crystal lattice vibrates and you see that doesn't depend on the calendar. Converting Unix time to local time obviously has to take that into account, but we still need an absolute measure of our progress does the timeline which is what Unix time provides.
This is why we use Unix time, it's the same everywhere and nothing short of relativity can affect it.
- aflag 7y agoAre you saying Unix time doesn't get adjusted when there are calendar changes in the box?
- toast0 7y ago> > Unix time is the number of seconds since 1 January 1970 00:00:00 UTC > Think of seconds in terms of some physical phenomena, like how many times a certain atom trapped in a crystal lattice vibrates and you see that doesn't depend on the calendar Unix time is NOT the number of physical seconds since 1970 UTC. It's the number of Unix Seconds since 1970. Every day has 86400 Unix Seconds. Some UTC days have more than 86400 physical days. Unix time cannot represent the seconds beyond 23:59:59 on a UTC day, but otherwise attempts to match UTC.
- tus87 7y agoUnix seconds ARE physical seconds. > Every day has 86400 Unix Seconds. Except a day with a leap second in it. > Unix time cannot represent the seconds beyond 23:59:59 on a UTC day, but otherwise attempts to match UTC. Err...it literally represents ~49 years beyond 23:59:59 on Day1 of UTC.
- toast0 7y agoWhat's the Unix Time for the UTC second 1985-06-30 23:59:60? My understanding is this physical second is not representable in unix time. How about the UTC seconds before and after that one, 1985-06-30 23:59:59 and 1985-07-01 00:00:00? My understanding is that the first is 489023999, and the second is 489024000. There is one unix second, but two physical seconds between the start of the two times.
- tus87 7y ago> What's the Unix Time for the UTC second 1985-06-30 23:59:60? My understanding is this physical second That's not a physical second, it's a calendar second.
- toast0 7y agoEvery UTC calendar second represents a physical second. On most days, every unix second corresponds with exactly one UTC second and they all correspond with exactly one physical second, and each one could be measured as the number of vibrations of some particular atom. On a day with a positive UTC leap second, it's different. At 12:00:00 UTC, it's 12:00:00 unix time, the next day at 12:00:00 UTC, it's also 12:00:00 unix time; 86401 physical seconds have passed, and UTC has counted 86400 calendar seconds, one of which was a leap second, but unix has only counted 86400 seconds. If you're running leap smearing, all of the unix seconds in that day are a little bit longer than the physical seconds (the exact details depending on your smear technique). If you're using classical techniques, 23:59:59 will be two physical seconds long, and the fractional second will reset to zero as the second physical second starts and count up again. In contrast to UTC, and Unix Time, TAI always has exactly 86400 physical seconds per day, but after a UTC leap second, both UTC and Unix Time will be offset from TAI by an additional second.
- pteraspidomorph 7y agoIf I understand what people are saying correctly, this is actually not true; leap seconds can not be referenced in Unix time and are not included in the unix timestamp value. They're just ghost seconds during which the counter stopped for one second. Which is not the way the system should have been designed, in my humble opinion. All seconds should be referenceable.
- tus87 7y ago> leap seconds can not be referenced in Unix time UNIX time does not represent/reference calendar time, it represents the number of physical seconds since 1970-01-01UTC. How you translate that into local calendar time is up to you!
- AgentME 7y agoIsn't this the opposite of what the article says?
- tus87 7y agoYes.
- AgentME 7y agoThe article's assertion that Unix time treats days as 86400 appears correct to me. Both Python and Javascript report 12-01-2019 UTC as the Unix timestamp 1575158400, 12-01-2000 UTC as Unix timestamp 975628800, and the difference between those is 599529600, which is exactly 19*365 days + 4 leap days as 86400 second days. The leap seconds added in 2005, 2008, 2012, 2015, and 2016 are all uncounted there. If Unix timestamps were the count of physical seconds that had passed since 1970/1/1 UTC, then the end result of my test should have been 599529605 instead of 599529600.
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- FabHK 7y agoIf what you said were true, then UNIX time were at some fixed offset to TAI. But it's not.