81–90 of 275 posts
Perhaps a stupid question: Why isn't there a time standard that is monotonic and defined simply in terms of seconds, without attempting to match the movement of the earth (no leap seconds, no negative seconds, no daylight savings, no complicated calendar politics)? If such standard existed, wouldn't it be the best to use for programming, with "simple" conversions to/from the all the other standards? Basically, I want…
I deeply disagree with point 3. Unix Time actually never goes backward: it just stagnates during a leap second. The article uses fictional fractional second to argue the contrary but I don't think it makes much sense. Unix Time is represented an integer and has no concept of such a fractional unit. That's an important distinction because it means that if you use Unix Time as a timestamp you can actually be sure than…
POSIX defines gettimeofday [1], which fills a timeval with integer (time_t) seconds and integer (suseconds_t) microseconds. Is your concern over weather Unix Time is a time_t or a timeval? A time_t shouldn't go backwards (in normal operation), but a timeval does. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...
Yes, you could put it that way. I view Unix Time as referring strictly to the time_t part (seconds since Epoch) but I might be the one in the wrong. I didn't remember that the timeval part existed in the standard.
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…
I read articles like this and come to the conclusion that UTC is flawed, not Unix time. Leap seconds seem mostly useless. People seem to think they are important for astronomy, but for every astronomical calculation I have ever done, your first step is converting from UTC to TAI. Move any jumps in time to once a century (or millennium). Such jumps have occurred in the past (Julian to Gregorian) and are easy to handle…
A notion of an instant in time that advances linearly without any ambiguities, which would be TAI, and a notion of the precise orientation of Earth, which would be UTC.
To record events, you will use TAI, to point your telescope to a celestial object, you will use UTC.
Earlier quoted context omitted.
You can set unix time to any value, including the future or past. If timestamps are recorded during those time-traveling epochs you will indeed see time go backward. Anyone writing time-aware processing needs to take this in to account, or they will eventually suffer for it.
Sure, you can manually force Unix Time to go backward but that's very different from what is argued in the article. If you do time-aware processing and mess with the clock you are using, you can except troubles. That's in no way unique to Unix time. Still, unless you actively mess with, Unix Time actually never goes backward.
The consequences show up in large ways, as well, especially in distributed systems. Calculating an order of events, for instance, based on some notion of time is an obvious flaw. Even within a single system, assuming that a time stamp can be relied on to indicate order of events is wrong.
If you work in domains where these things are important you will eventually come to understand that simplistic and naive statements such as "unix time never goes backwards" are the swords that programmers eventually fall upon.
Here's a falsehood I've seen a bunch of times: the idea that Unix timestamps need to be converted to your local timezone. Unix timestamps are the number of seconds since a specific date in a specific timezone (UTC)! If a user gives you a Unix timestamp and you know they're in the PDT timezone, you should not add or subtract 7 hours of seconds to "convert" the timestamp to UTC! It already is. Similarly, if your client…
Some probing questions: Alice and Bob both live in England and have planned a conference call at 15:00 on 4-jan. Now Alice happens to travel, and she is in American on 4-jan. What should here calendar do? Moreover, Alice also has a recurring event "Workout" every friday at 9:00, what should that shift to? Finally, it turns out Bob is also in America, what time should the conference call be at now? Finally, for some r…
However, I saw a good tip once that you should only store timestamps of past events and events that happen at a fixed instant regardless of calendars and wall clocks as Unix timestamps. Timestamps for things like future calendar appointments (that may be affected by future changes in regions' timezone definitions) should be stored as a date and wall clock time and regional timezone, and only converted to a Unix timestamp when it happens. This makes it possible to see the timezone the user intended, let it be changed, and works well even if timezones themselves change before the event happens.
Earlier quoted context omitted.
> > 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…
Unix 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.
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.
I was aware of leap seconds after working for an online auction website. How to deal with all the auctions that may be ending right at or before the leap second? Our solution was simple: temporarily pause all the auctions :) We already had site-wide "auction pause" code as a result of people DDOS'ing the site.
Everything went as planned on our side of earth. But our local asian in Japan, managing several colocations in Asia (Jp/hk/singapore/india...) were thinking this leap second was at midnight LOCALTIME.
I just remember the mess they had to deal with, the day after. Cause midnight UTC is not midnight in Japan, hft is over sensitive to time coordination. shifting forward or backward 1sec can close your connection to market.