Never ending nutrition
A very circuitous discussion on our relationship with time zones from the perspective of a programmer.
Recently, I was dealing with a software bug. Well, it was kind of a time zone issue? Nope. Definitely a server/deployment problem. As you can tell, it was a confusing one to define. It first manifested when, even though tests were passing, expected behavior was absent in production: our once daily notifications triggered by
cron weren’t sending. So, I checked out the logs, found a SQL syntax error due to a SQL incompatibility between SQLite3 (dev) and MySQL (production), and fixed it. Expecting that since I deployed the fix before noon and the scheduled job that would execute the fix should run at 1730, I thought that we’d see the working notifications later that day. No such luck — the same error happened again! Based on what I understood about the problem, the new code should disallow the possibility of that error occurring at all. Well, digging in a little more, it seemed like the errors were happening at the wrong time. The job was set to run at 1730, the server time was set to MST as seen by using the
date program, but the jobs were running at odd times. My first theory, which turned out to be correct, was that a running
cron service does not dynamically pick up changes made to a system’s time zone. Thus, if the server had only been booted once, and
cron was started prior to the time zone being changed to MST, then
cron would still be running on UTC. I plopped a dummy job into the
crontab that appended the
date output to file and played around with the times it was supposed to run and saw that jobs were running 7 hours earlier than they should. I left the dummy job in place while
cron restarted and the
date entries stopped appearing. Once the dummy job’s time was set back 7 hours, the
date entries started showing up again! Easy fix for an issue that took some digging to figure out.
One dead end approach that turned up something interesting was trying to look at the environment of a running process. As I was researching
cron, it seemed like inspecting the
TZ environment variable for the process could show the discrepancy. It ended up that that variable was not set at the time the process was spawned, but learning how to look at the environment a process was spawned with was interesting:
psto determine the
PIDof the process to look at
cat /proc/<pid>/environ(basic approach)
There are a few more suggestions here.
Ok, so technically it’d be UTC, but GMT just sounds better. What is a time zone anyway? This is totally not researched, but my guess is that time zones are useful for making the same parts of the day happen at approximately the same. Noon is around when the middle of the daylight hours are, or something like that.
Anymore I feel like maintaining such a system is inefficient and will continue to become more so. As programmers write more and more software to automate our global lives, how much will be lost because of time zones and daylight savings time? It seems silly that, in an always-on world, we’d be needing to waste cycles on determining what time it is in another place. Instead, if we could standardize on a 24 hour clock where the current UTC noon is the current UTC noon, we could start abandon any mental or computational thought on the subject.
Obviously, I’m not putting enough thought into how many existing systems this change would break. It is wonderful to think about how simple we could make it if we wanted though…
What’s the deal with all these awkwardly spaced time parts?!
Alright. Well, we humans have ways of dealing with this. It’s called the metric system. Kind of. The metric system, or more generally, the International System of Units (SI), has to do with measuring things. In the case of time, it provides a measurement called the second, which is used to measure time duration. Originally, it was defined as 1/86400th of a “mean solar day”, but is now based on something something cesium something. Pish posh.
Well, the SI second doesn’t help us too much in terms of making our different time segments related in terms of powers of 10. There’s a different system for that called Decimal Time which splits a day into 10 hours, each with 100 minutes, each with 100 seconds. The odd part about this system is that, even though the name of each segment (hour, minute, second) is the same, their lengths are each different from what we’re used to. That would feel a bit odd at first…
A random bit of trivia for you. The Swatch company, in the 90s, created an alternate time system based on Decimal Time (see above) called Swatch Internet Time. Each
.beat was equivalent to the duration of one decimal minute, meaning that there were 1000
.beats in a day. No time zones were recognized and the goal was to create a time system that citizens of the internet could use. Pretty ahead of their game, no?
All this writing was a lot. I know. But, it’s been on my mind a lot lately, what with all the space talk, programming issues, and Hacker News discussions. Maybe you learned something? Or, maybe you’re just mad for reading this far.
So, I’m releasing a new Ruby gem and would like to explain some of the backstory.
Recently, I worked on a small Rails contract and part of the work was to fix a bug where a person’s age was being displayed wrong. The format desired was “X years X months X weeks X days” but the calculation seemed to be inconsistently off by a few days. The project had been using the time_diff gem, but after examination, it was clear what the problem was: it was using standard lengths for the months. Although, 316 days is technically ten months, two weeks, and two days if every month has 30 days, every month does not have 30 days. So, I started looking at other options:
end_date, which doesn’t seem to be how humans think about this type of calculation
time_diffwith some very minor changes.
Based on my findings, I decided to create a new gem with the following goals:
spancan and should get better.
I’m really looking forward to feedback on
span. Check it out, read the code, and send issues and pull requests with feedback.
Try as I might, I can’t shake the feeling that 2014 is the year we lose the Web. The W3C push for DRM in all browsers is going to ensure that all interfaces built in HTML5 (which will be pretty much everything) will be opaque to users, and it will be illegal to report on security flaws in them…
what does the internet look like in space? instead of having one, there should be an infinite number of them.
naming: they’ll have to know how to link when they are able to connect to other ones. maybe some sort of meta-DNS service to apply another name/level above a TLD. vanilla TLDs like “google.com” will always look within the current internet. for the sake of example, let’s say there were optional Location Level Domains that succeeded TLDs in a domain name. Earth’s internet could optionally be “.earth”. thus, “google.com.earth”. The ISS could be accessed from earth as “google.com.iss”.
services: services will need to be more automatic with functionality like discover and autoconnect being built into devices. for example, voice communications. a personal communication device, upon gaining connectivity to a network, should be able to make itself known as a voice communications device and be seen by other devices and see other devices.
automation: when two networks make a new connection, they should be able to bridge traffic between their existing connections. they should also automatically be able to do things like trade news or other data if routines are built in to do that.
currency: things like automatic currency ForEx should be possible when new network connections are made between internets. this could be for profit or simply to ensure currencies are denoted as required. also, services and other connections will probably charge for usage. this will probably be in minuscule amounts and happen automatically if within user-defined or default thresholds.
cloud: serious data storage, cpu, ram, etc. usage will probably always be performed remotely in hardware banks over network connections. these hardware banks will be on planets/moons, ships, satellites, asteroids etc.. like other services, they may partake in an automatic bidding process with requests for their usage to determine task priority. a ship owner might have higher priority than the port being docked at for cpu time. probably in something like a rackmount, hardware can be swapped or repaired as needed depending on manufacture and availability.
it’s unclear to me how many people on our planet are interested in getting off of it and into space. it seems like it could be universal dream, but at the same time too amorphous to be constantly inhabiting most peoples’ minds. we face so many distractions daily that it is easier to forget our own dreams, space or otherwise. things like politics overshadow our attempts at progress in the areas of education, healthcare, and finance, to name a few. wars and warlords spread chaos and hold people back from their birthright of determining and acting out their own destinies. fanaticism and partisanship use emotion to cloud the truth behind a multitude of issues. ecological disasters spread negativity and hopelessness as if we are unable to change our situation.
but, the concept of a shared dream, or rather, a shared vision is powerful. it provides a baseline for action and decision-making. it can give people the confidence and conviction that something is for the common good. if we consider the idea of humans permanently inhabiting space as a shared vision, what would we gain? here are a few ideas:
unification: we could cut through the self-imposed complications of our societies and lives and create something that we’re all working towards. politics become less important compared to progress. wars can be seen as taking resources away from the shared vision.
economies: we have yet to see what our nations would be like with serious public and private financial resources brought to bear around a shared vision like this. imagine the progress if citizens, businesses, and governments started to collaborate on supporting moving humans off-planet. whole new business sectors would be open for innovation and entrepreneurship.
ethical advancements (this might not be an appropriate term): for a shared vision to manifest, everyone has to believe the outcome is universally good. people must have guarantees that their hard work will pay off. they will have more freedom and a safer life. they will have a better guarantee of a positive and safe future for their descendants. to make these sorts of guarantees enforceable, new types of contracts and business charters will be needed. what does a B-Corp look like in the realm of outer space?
essential environmentalism: to support the necessary progress, humanity will have to dig deep. that is most likely a figurative and literal statement. we are only beginning to understand and measure the ways that we impact our environments. this science will have to improve and affect our resource gathering and operations as move upward and outward. to have a clean and inhabitable is not just a noble goal, but a necessity to support our progress. by simultaneously improving our environment while collecting more resources, we can ensure that we will always have at least one home base for the time being.
efficiencies: with a common vision, efficiencies or a lack there of become much more visible and measurable. bureaucracy can be minimized through technology and a reassignment of resources towards the common vision.
these things are probably a very small part of what we could gain. also, these things are not necessarily even at a national (USA) level, but global. new treaties could be signed, uniting our governments and peoples together in such a purpose.
all of this is postulation. any progress along this front would be very challenging. by making these statements, i am not saying they are original thought, but rather reflections on what i see in our world and in what i experience.
Wrote a little tutorial/playbook on turning an iPad 1 into an Ansible node.