You also have your spring in our autumn, and your autumn in our spring, though.
1 Like
No, its the other way around; You follow us.
6 Likes
Yeah exactly, you say autumn we say fall. Totally different.
2 Likes
Know that you are not alone. In fact, the reconciling of apparent cycles (stellar, lunar and solar) has been the primary problem for all of human history.
1 Like
I half jokingly half seriously promote the “One World Time Zone” from time to time. I don’t claim it will solve all our problems and not cause any others, but I don’t think it’s likely to cause any more problems that what our current system of time zones causes now. Time zones were created to deal with trains that for once could move people fast enough to have the rotation of the earth matter to them, but not fast enough that they could ignore the differences between one point an the next. That largely held until the telephone, and has been breaking down since then. The solutions to the problems that time zones create tend to be learned almost subconsciously at an early enough age that most people never realize they are mentally compensating all the time.
Our more interconnected world has shown these problems to exist more if you take the time to look, but most people don’t need to look and so they (rightfully) don’t.
Time zones are not time keeping systems. Not having time zones or daylight saving time/summer time would not destroy time keeping. Hour would still be hours, days would still be days, nothing would really change. Does it really matter from a practical stand point if I’m writing this at about 2pm or 7pm? It is both of those times and neither of those times for me right now. Does it matter that I plan to leave work in three hours and that could be at 5pm or 10pm?
In either case the sun would just be starting to set, it’s an arbitrary number that we have made up the meaning for, both of those numbers are equally false, the real actual solar time is not 2pm, and I won’t be leaving work at 5pm, because we have by government decision decided that we will lie about the time shown on clocks for the majority of the year. We have done it enough that the lie feels like the truth and the truth like a lie. The last proposal I heard to end daylight saving time was to make it, the fake time, last all year long.
Picking some other lie about what time our clocks show won’t make it any more or less right.
The reason I’m not actually fully serious about a one world time zone is that it’s a good solution for a very minor segment of the total population. Those of us that regularly work with international colleagues often find time zones and all the rules around them are a impediment to collaboration instead of a help. Throw in northern/southern hemisphere seasons and the corresponding opposition time changes 4 times a year instead of 2 and trying to schedule any thing more than a few weeks in advance gets hard fast.
2 Likes
For an alarm, my first pass at reconciling those issues is that the alarm should always go off exactly once, at the first time which is equal to or greater than the time it was set for. So an alarm set for 1:30 on spring-forward day would go off at 2:00, an alarm set for 1:30 on fall-back day would go off once at the first fall-back, etc.
I am absolutely certain there is some case for which that breaks, but I don’t know what it is.
I was horrified to find that RTC chips have a built in, hardcoded calendar computation. You can’t find a battery-backed RTC which just counts monotonic [milli]seconds, they all insist on being “nice” and “easy to use” by giving you output in years/months/days/hours/minutes/seconds. Of course, if you want to even come close to handling calendar time properly in software, you’re going to be starting from an absolute-time-since-epoch base and computing calendar time from that, so you’ll have to reverse-engineer the calendar functions of the RTC to get back to a monotonic second count first and then re-do all the calendar computations on top of it…
1 Like
Leap seconds are objectively evil in this context because they don’t even have the decency to be deterministic (by means available to present observers at least; though if your computer timekeeping system needs to incorporate a model of the universe whose accuracy exceeds our current predictive abilities even the discovery that they are deterministic, just subtle, won’t be much consolation).
There’s the list of annoying special cases; and then you leap several categories in a single newline and reach the “well, they say the quasars have wobbled a bit; add a second” rule.
TAI 4 lyfe.
3 Likes
No, they were against the very idea of leap seconds. They were fine with the idea that “computer time” would drift away - quite radically - from solar/astronomical time.
Yeah, because that’s worked sooo well for China. (Note: sarcasm. The reality is that, fed up with the sun setting at midnight, the further West you go, the more people use unofficial local time zones - especially with some ethnic groups estranged from Beijing culture; the result is you never actually know who is using what, creating even more chaos.) Time zones weren’t just created for trains - the whole industrial idea of standardized times and time zones was about standardized work schedules, in large part. Leaving aside that the ideas of “noon” and “midnight” have significance to people, the lack of local time zones means you have no idea what anyone’s schedules are, like with China’s Western areas. You think it’s a pain trying to schedule with distant colleagues now, imagine if each office had its own, unofficial clock that governed work hours.
1 Like
Any decent programmer should know that time is extremely and insidiously hard to get right. Which is why you should never roll your own time code - always use OS and common framework code to do this and carefully think through any time based calculations that you’re making. Better hope you don’t need to consider general relativity in your calculations!
Here’s a good problem to consider: your program is running on a cruise ship that’s frequently changing between time zones (both forward and backwards).
7 Likes
Yeah, I’m a developer. The whole “devour the whole project” is a bit dramatic. Typically with time and dates you use libraries or built in functions. Daylight savings is a predictable boundary case, and it would be easy enough to test if you had an app where its behavior around dst was critical.
2 Likes
Most of the built in OS and the default date/time libraries for most languages are ok for general use case of asking about dates, but do a very bad job at date manipulation.
Nearly all of them fail in some way for common use cases. One often gotten wrong is asking for the same day in the next month when your near the end of the current month. Very few will document what they expect to happen when you add one month to January 30th. Valid technically correct answers include throw an exception, return February 28th (or 29th), or March 2nd (or 1st). I’ve seen all three done in one library or another.
I’ve seen plenty of other odd cases where a nice numeric view of dates doesn’t match up with the messy reality of dates and the library was coded for simple behavior and not all the odd rules that could exist.
2 Likes
But… if I have a date in Constantinople will she be waiting in Istanbul? Follow up question, will she be there at 1am or at 1am?
2 Likes
Yes. One of my biggest annoyances with my MS Exchange calendar is the way events change time when I change time zone. Say I’m traveling, get an email from a colleague saying “let’s meeting next Thursday at 2:00,” and put it in my calendar. When I get home, they meeting has been changed to 1:00.
Maybe some people think this is nifty behavior. I hate it. I can keep track of which time zone I’m in better than I can keep track of every meeting in my calendar.
4 Likes
To move away from time for a bit, but related to your point about timezones … my pet hate at the moment is the way websites display prices: $76.21
What’s wrong with that, you ask? Ok, which fucking dollar are we talking about here - mine, yours, someone else’s? It makes a big difference to the price I pay and ironically, it’s gotten worse in the last few years, with some websites automatically detecting where I am, and applying my $ to the price. But they don’t tell you they’re doing it, and nothing about the presentation indicates what’s been done, and it’s applied inconsistently across websites and across the intarwebz. At least back in the day I could assume simple xenophobia, and any $ prices on a .com site would be in US$. Now it’s a fucking lottery.
The solution is stunningly simple: display your gorram currency clearly: US$ or AU$ of ZM$ or whatever the fuck it is. I. Don’t. Care. I don’t care if the price is in US$, I can do the exchange rate by myself just fine. It’s nice if you present the price in my $, but if you do that, TELL ME. Right there. In the fucking price. For every single product on every single page there is a price displayed.
Also, if you’re selling shit on teh webz: learn about gorram freight forwarders. I will happily buy your shit, but NOT IF YOU WON’T SEND IT HERE!
/r
10 Likes
To be clear, that’s what Google famously does, and AWS EC2 to the best of my knowledge. Many people dependent on them naturally follow them. Many other systems do a hard jump (the easiest, and hence default), or smear it over a shorter or longer period.
Others, such as the Single Unix Spec bite the bullet and allow minutes ending in :60. (Early POSIX did not, but was also broken about time in many other ways.)
If you’re using the Olson Timezone database (most Unix systems do), you can actually do this and keep a true count of seconds since the Unix epoch of Jan 1 00:00:00 UTC 1970, the trick is to prefix the timezone with “right/”:
% TZ=right/UTC date -d ‘@1435708825’
Tue Jun 30 23:59:60 UTC 2015
% TZ=right/US/Pacific date -d ‘@1435708825’
Tue Jun 30 16:59:60 PDT 2015
% TZ=UTC date -d ‘@1435708825’
Wed Jul 1 00:00:25 UTC 2015
As you say, lots of stuff breaks, including, ironically, many NTP clients.
But hey, unlike Windows, at least the underlying data isn’t kept in localtime!
2 Likes
Not everywhere. I personally know of a radar tracking system where one end of the interface slews instantly, while the other one takes maybe half an hour to get back in sync. The system requires both ends of the interface to be accurately synchronized with time from GPS.
1 Like
Offsets are not timezones, timezones have offsets. (Just trying to make it more complicated for you 
)
1 Like
#winzthenetstoday!
3 Likes
