Falsehoods programmers believe about Unix time
221–230 of 275 posts
Re: Falsehoods programmers believe about Unix time
#222Earlier quoted context omitted.
Well, the problem with this is that every simplistic view at time is... well... too simple. It's not that many people haven't tried, I especially like this article: https://qntm.org/abolish That being said, why your approach doesn't work is that there are several hard astronomical or cultural definitions that you'd throw off by playing with time. A day is defined as the rotation of the earth around its axis. A week i…
We should abolish local time too. There should be a single time for every country which is the number of milliseconds since either the beginning of human civilization, the beginning of earth or the universe.
A. Why?
B. If you want to be super strict about it, as I imagine you do, that scheme would hit problems with relativistic effects. Local time is the only real time.
Re: Falsehoods programmers believe about Unix time
#223Earlier quoted context omitted.
In your case, you're not doing the specific thing I prohibited. I only meant you should never do arithmetic on a timestamp to try to "convert" it to an equivalent representation of the same instant (as Java 8 defines it) in another timezone. However you're specifically doing arithmetic on the timestamp to calculate a new different instant, which is fine. (Your case isn't that different than the user pressing a "shift…
> 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 I think this works more often than not, but it's hardly foolproof or without repercussions. Say, you can imagine Google Calendar having a list of holidays for the US. Say it's New Year's day. You're saying you'd replicate that into 6 epoch timestamps (one per time zone…
Yes. This sounds a bit silly for New Year in particular because its timing is slightly less arbitrary than other holidays', but holidays move around: https://en.wikipedia.org/wiki/Uniform_Monday_Holiday_Act
Re: Falsehoods programmers believe about Unix time
#224The original purpose of Unix time was decoupling local time representation and internal timekeeping of the system. Unix time could be the "One True Time" of the system, it always increases monotonically. When you need local time, all the tricky and nasty details, including DST, mandated calendar changes, etc, are processed by the tzinfo system library/database. If the calendar has changed, at least in principle one d…
Obviously, given the article and the discussion I am wrong, but what you propose sounds to me exactly like the definition of unix time:
The number of seconds since January 1. 1970 UTC.
Even if UTC counts the same second twice, this does not change how many seconds has elapsed since the unix epoch.
If you click through the articles reference to wikipedia and again from there, you will end up on "The Open Group Base Specifications Issue 7, 2018 edition"[1]
Which says:
> The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified.
Which again sounds like there is absolutely no reason to double count or skip seconds in unix time.
However, I am not quite sure of the implication of the formula written there, but I fear that it says that the number of seconds since the epoch is defined, not as the number of seconds since the epoch, but by the UTC definition of the current time.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...
Re: Falsehoods programmers believe about Unix time
#225Earlier quoted context omitted.
> come to the conclusion that UTC is flawed The different time definitions exist to support different use cases. UTC isn't flawed, in fact the adjustments that keep it aligned to solar time are very helpful for its defined use cases. It's just that time is complicated. If you think you will be doing time math where duration is paramount consider using TAI. PS: for all those who think 'time' is complicated in fascinat…
Well, time is complicated, but not for reasons that really matter to 99.95% of engineers (relativity and such). At its most basic level, Time is really just a monotonically increasing counter of seconds (or ms or ns or whatever). That's it. The problem is really the cultural and societal layers on top of it. That's not Time's fault, its Our fault. A "Day" has to be 1 rotation of the earth around its axis, a "Year" ha…
Ah yes, the spherical cow of software development: it's much simpler to build software which interacts with nothing and especially nobody.
Re: Falsehoods programmers believe about Unix time
#226Earlier quoted context omitted.
I know it will never happen because of cultural reasons, but really, we need to separate the time (as in how I describe a point on the time scale, for, let say, a meeting, especially one that involves people in globally distributed locations), and the cultural aspect (at what time people are sleeping or eating lunch). Right now those two things are intertwined, and that's bad. Not everyone eats lunch around noon or g…
Swatch Internet Time: https://en.wikipedia.org/wiki/Swatch_Internet_Time
And Julian day:
Re: Falsehoods programmers believe about Unix time
#227Earlier quoted context omitted.
Unix timestamps have no inherent time zone at all. They are a quantity of seconds (ignoring leap seconds & relativity) since a specific instant. That instant in time happens to conveniently line up with 1970-01-01T00:00 when described in UTC to make things easy for us. But it is equivalently defined as 1969-12-31T16:00-08:00 when described in another time zone. The elapsed quantity of seconds since that instant does…
I think that's a better way of putting it. The main lesson is that there's no operation called "changing the timezone of a Unix timestamp", and any code trying to do that is wrong. A date string is a function of a Unix timestamp and a timezone, and if you need to change the timezone, you need to pass a different timezone parameter, not try to do something to the Unix timestamp part.
> A date string is a function of a Unix timestamp and a timezone
If offset or zoned. Sadly the average date string has no more inherent timezone information than a unix timestamp.
Re: Falsehoods programmers believe about Unix time
#228Earlier quoted context omitted.
Well, the problem with this is that every simplistic view at time is... well... too simple. It's not that many people haven't tried, I especially like this article: https://qntm.org/abolish That being said, why your approach doesn't work is that there are several hard astronomical or cultural definitions that you'd throw off by playing with time. A day is defined as the rotation of the earth around its axis. A week i…
We should abolish local time too. There should be a single time for every country which is the number of milliseconds since either the beginning of human civilization, the beginning of earth or the universe.
I like Swatch Internet Time.
Re: Falsehoods programmers believe about Unix time
#229Earlier quoted context omitted.
500 years from now, if we're still alive, enough of us will be living in space colonies rather than on the Earth's surface that the Earth's rotation will not necessarily be immediately relevant to everyone's lives. Regardless, we've had maybe half a minute of drift since the 1970's. If the drift is 1 minute in the 2000's, 1 second per year in the 2100's, 2 seconds per year in the 2200's, 3 seconds per year in the 230…
We need a pseudo day still due to our sleeping rhythms but perhaps people could choose that based on personal preference not just stick with 24h
I'm reasonably sure that any assumptions about how our anatomy will look like in 500 years are more wrong than right.
Re: Falsehoods programmers believe about Unix time
#230I don't understand this one: > If I wait exactly one second, Unix time advances by exactly one second How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds. I feel like this is wrong too: > If there’s a leap second in a day, Unix time either repeats or omits a second as appropriate to make them match. It's not Unix time doing that. It's UTC.
> How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds.
No, but it means UNIX time does not advance by exactly one second per elapsed second. Instead it advances by either 0 or 2.
> It's not Unix time doing that. It's UTC.
It's also unix time. unix time is (86400 * days_since_epoch + seconds_since_midnight). A leap second means a day is not 86400 seconds, and thus you'll either get a skip or a repeat on midnight rollover.