101–110 of 321 posts
Earlier quoted context omitted.
Every bank I've ever been a sucker-err-customer of seemed to use whichever order results in the most fees. Not the only reason I use a credit union these days.
There used to be a law against that in the US, but the GOP repealed it early in Trump's first year.
Love this article, but one thing it skipped on was more in-depth on Leap Seconds. You see, UTC, is kinda like another human-made-up timezone. Humans made up some rules, and UTC is a 37 second offset from TAI / International Atomic Time: https://en.wikipedia.org/wiki/International_Atomic_Time
Right? And that that 37 second offset will change from year to year? I was waiting for the bombshell, that some minutes actually have 61 seconds in them, and some have 59 seconds (though it occurs to me that I don't know if astronomers ever add or subtract more than a second for any given clock adjustment).
TAI if you can work it out :)
Earlier quoted context omitted.
Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, regardless how many time zone changes you may have. What does change is the method to compute the time difference. So can you say how many days, hours, minutes, seconds ago that was from: 2043-02-12T11:15:16+02:00 You won’t be able to, because then you have to account for leap seconds, etc. Also “next Tuesday” does have to take into acc…
It depends. It could be a meeting in a particular city at 4pm local time. A "+02:00" or "-05:00" specifier is insufficient because the government of the particular city/country might change the time zone rules between now and when the event is to occur. So you really need to store "2018-08-01 16:00:00 America/Argentina/Buenos Aires" for example, because maybe after 2018-06-01 they decided to go for "-05:30".
a) "I'll be there in 12 hours", implication being that if there happens to be a DST change, it doesn't matter.
and relative calendar time
b) "I'll meet you 15:00 next monday".
Both of which are valid.
What's interesting is: which of these is most useful in programming, generally? Which should the APIs make easier, or even cater for at all?
I would submit that most applications only care about "physical time"[1], but specifically [b]logging[/b] is actually really interested in calendar time. Fortunately, with logging there's so much volume that you can usually tell pretty easily when there's been a discontinuous time event -- it's a pain in the ass to rebuild timestamps, post hoc, though.
[1] Calender-type application is actually pretty niche IME. Opinion may vary.
Slightly off topic but I wonder how you handle time where dilation is present. For example if a spacecraft travels to mars and there is mars local time, plus time dilation from the journey, when does a transmission start from a reference frame? Not UTC related for sure! Or is it? And then what happens if someone else goes there in a different orbital pattern and the dilation is different. and then there is the questi…
This is a very old problem and not limited to spacecraft. If you sail around the world eastward, each of your days is slightly shorter than the days of your countrymen and by the time you get home, you will have experienced a full additional day-night cycle. I think the solutions would be the same: separate timekeeping standards where it makes sense, like Mars, and frequent corrections to spaceships' clocks to keep i…
So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…
Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, regardless how many time zone changes you may have. What does change is the method to compute the time difference. So can you say how many days, hours, minutes, seconds ago that was from: 2043-02-12T11:15:16+02:00 You won’t be able to, because then you have to account for leap seconds, etc. Also “next Tuesday” does have to take into acc…
It will respective to the local time though if a state decides to stop honoring DST or changes TZ.
The reason why we use numbers like 12 and 60 and 360 in time and length, from ancient times onwards to today, is because these numbers have many divisors, meaning that they can be divided many different ways without needing decimals.
12 can be divided by 1, 2, 3, 4, 6, 12 (i.e., it can be divided in half, into thirds, fourths, sixths). By comparison, you can't cleanly divide 10 into thirds or fourths without using decimals.
60 can be divided a whole bunch of ways: it can be divided by 1,2,3,4,5,6,10,12,15,20,30,60. The same is true for 360 (e.g. degrees in a circle).
Even in the modern era, where we understand decimals and everyone is trained on them, it's convenient to be able to perform common operations on common units without having to involve decimals. It's convenient that an hour can be divided into three 20-minute periods, or two 30-minute periods, or six 10-minute periods, and so on.