This way lies madness.
December 31, 2013 2:41 PM Subscribe
The problem with time.
That's why you guys make the big money.
posted by Thorzdad at 3:10 PM on December 31, 2013 [2 favorites]
posted by Thorzdad at 3:10 PM on December 31, 2013 [2 favorites]
Sometimes I feel like I work in bizarro land where people other than just programmers (designers, UX, strategy, producers, product/account, client, analytics, qa etc) plan and design programs. This is what business requirements and use cases are for, so you don't have "'Allo! Samoa CAWLING!"
posted by sweetkid at 3:13 PM on December 31, 2013 [2 favorites]
posted by sweetkid at 3:13 PM on December 31, 2013 [2 favorites]
Having flashbacks to my last job where I had to debug test scripts running on hardware in California but remotely controlled from a test queuing system in Pittsburgh. So the logs for a single run could have timestamps in EST, PST or UTC depending on what layer wrote it. Not only that but some of the test utilities output their timestamps in epoch seconds. My brain hurts just remembering it.
posted by octothorpe at 3:17 PM on December 31, 2013 [2 favorites]
posted by octothorpe at 3:17 PM on December 31, 2013 [2 favorites]
I recently had a teammate on my project who would not get the most trivial part of this through his head. A distributed app being used simultaneously by multiple users in multiple time zones, and I continually not only had to repeatedly fix his code to stop using client-side dates in DB queries (yes, writing as well as reading), but even got into revert wars with him because he would change it back again. Your server should never, ever see a date that is not your single standard -- typically UTC for most ordinary uses. Really, time conversions should only be done at presentation time, at the user-facing i/o level and nowhere else.
posted by George_Spiggott at 3:18 PM on December 31, 2013 [11 favorites]
posted by George_Spiggott at 3:18 PM on December 31, 2013 [11 favorites]
BRING BACK SWATCH TIME
posted by Foci for Analysis at 3:19 PM on December 31, 2013 [11 favorites]
posted by Foci for Analysis at 3:19 PM on December 31, 2013 [11 favorites]
And then you get a call from Thailand. Everything's crashed and the computer is on fire. What happened? Well, someone tried to calculate the difference from today (31 Dec 2013, the world) to yesterday (30 December 2556, Thailand) and the resultant delta was -1.71354e10 seconds.
posted by flyingfox at 3:22 PM on December 31, 2013 [9 favorites]
posted by flyingfox at 3:22 PM on December 31, 2013 [9 favorites]
I will generalize this topic. The time seems apposite.
THE TOPICS OF PROGRAMMING INSANITY:
1. Time. This very topic.
2. Color. Color 'science'. Color mixing. Run and hide.
3. Typography, and it's little friend, text layout.
There are no doubt others--these are the ones that have bit me most memorably.
posted by hexatron at 3:23 PM on December 31, 2013 [2 favorites]
THE TOPICS OF PROGRAMMING INSANITY:
1. Time. This very topic.
2. Color. Color 'science'. Color mixing. Run and hide.
3. Typography, and it's little friend, text layout.
There are no doubt others--these are the ones that have bit me most memorably.
posted by hexatron at 3:23 PM on December 31, 2013 [2 favorites]
Time zones were the bane of my existence for most of 2011. I have truly, honestly, never had so much trouble in my two decades of software development as when having to implement a calendar with time zones. I still have nightmares.
posted by Lokheed at 3:23 PM on December 31, 2013
posted by Lokheed at 3:23 PM on December 31, 2013
One of my bugaboos at work is that a number of important logs have dates that are in 12 hour time... with no AM/PM value. Given that grep is my log tool of choice, it's annoying as hell.
posted by tavella at 3:24 PM on December 31, 2013
posted by tavella at 3:24 PM on December 31, 2013
So very, very true. Time—or, more precisely, timekeeping and calendar systems—are an absolute nightmare.
Store everything internally (and perform all your calculations) as UTC. Convert to the user's local time zone for display. It'll still be a nightmare, but at least it won't be a non-Euclidean Lovecraftian nightmare.
posted by escape from the potato planet at 3:32 PM on December 31, 2013 [2 favorites]
Store everything internally (and perform all your calculations) as UTC. Convert to the user's local time zone for display. It'll still be a nightmare, but at least it won't be a non-Euclidean Lovecraftian nightmare.
posted by escape from the potato planet at 3:32 PM on December 31, 2013 [2 favorites]
This guy, and his practiced gravitas, is gonna go far.
posted by OHenryPacey at 3:32 PM on December 31, 2013 [1 favorite]
posted by OHenryPacey at 3:32 PM on December 31, 2013 [1 favorite]
The one historical thing I'm sad he didn't get to was the fact that revolutionary France decided that time was insufficiently rational, and moved to the Republican French Calendar, which, starting on September 22nd, 1792:
1. Had 12 months (all good so far) of exactly thirty days each
2. Each month was three ten-day weeks
3. Had the 5-6 days remaining added onto the end of the calendar after, you know, the months
4. Started on the fall equinox
And they also moved over to decimal time, with each day being ten hours long, each hour being 100 minutes, and each minute being 100 seconds, which of course means that none of that matches up with anything (1 decimal hour being 144 minutes, 1 decimal minute being 86.4 seconds, and 1 decimal second being 0.864 seconds), at which point I'd imagine I'd be shot dead by the programmer for even suggesting such a feature.
posted by Punkey at 3:33 PM on December 31, 2013 [5 favorites]
1. Had 12 months (all good so far) of exactly thirty days each
2. Each month was three ten-day weeks
3. Had the 5-6 days remaining added onto the end of the calendar after, you know, the months
4. Started on the fall equinox
And they also moved over to decimal time, with each day being ten hours long, each hour being 100 minutes, and each minute being 100 seconds, which of course means that none of that matches up with anything (1 decimal hour being 144 minutes, 1 decimal minute being 86.4 seconds, and 1 decimal second being 0.864 seconds), at which point I'd imagine I'd be shot dead by the programmer for even suggesting such a feature.
posted by Punkey at 3:33 PM on December 31, 2013 [5 favorites]
Yeah, yeah, time is a beeyotch.
Now factor in working days, working hours, and location by location celebrated holidays and special hours in your scripts, both standard and custom, and make projections, calculations, and contractual obligations on millions of transactions an hour using all those factors.
Our boss is a certified Super Geeeeenius.
posted by tilde at 3:34 PM on December 31, 2013 [1 favorite]
Now factor in working days, working hours, and location by location celebrated holidays and special hours in your scripts, both standard and custom, and make projections, calculations, and contractual obligations on millions of transactions an hour using all those factors.
Our boss is a certified Super Geeeeenius.
posted by tilde at 3:34 PM on December 31, 2013 [1 favorite]
Oh god, oh god... Hope you've got a good DateTime object (clue: if it is JavaScript you do not) or do everything in EPOCH and do a lot of converting back and forth...
Of course, every so often it will be decided that users want to do things that don't readily translate into the number of microseconds since the dawn of UNIX, like pick a date without specifying timezone or whatever, and you'll have to make assumptions and the assumptions will be wrong or come with complications...
Arrrrrgh.
posted by Artw at 3:36 PM on December 31, 2013 [1 favorite]
Of course, every so often it will be decided that users want to do things that don't readily translate into the number of microseconds since the dawn of UNIX, like pick a date without specifying timezone or whatever, and you'll have to make assumptions and the assumptions will be wrong or come with complications...
Arrrrrgh.
posted by Artw at 3:36 PM on December 31, 2013 [1 favorite]
Store everything internally (and perform all your calculations) as UTC. Convert to the user's local time zone for display. It'll still be a nightmare, but at least it won't be a non-Euclidean Lovecraftian nightmare.
But be cognitive of whether the switch is happening on the server side or on the client side. On the client side different browsers treat javascript date objects differently. For that matter, just a few days ago I had to troubleshoot a third party calendar module issue where it turned out it dealt with up to three different time zones (server time, client time, plus a profile setting for the user's preferred time zone). Ugh.
posted by Lokheed at 3:37 PM on December 31, 2013 [1 favorite]
But be cognitive of whether the switch is happening on the server side or on the client side. On the client side different browsers treat javascript date objects differently. For that matter, just a few days ago I had to troubleshoot a third party calendar module issue where it turned out it dealt with up to three different time zones (server time, client time, plus a profile setting for the user's preferred time zone). Ugh.
posted by Lokheed at 3:37 PM on December 31, 2013 [1 favorite]
octothorpe: epoch seconds are more reliable, and less ambiguous, than any common alternative
posted by idiopath at 3:38 PM on December 31, 2013 [3 favorites]
posted by idiopath at 3:38 PM on December 31, 2013 [3 favorites]
The whole computerphile series is pretty bomb. (SSD wear explained)
posted by phaedon at 3:39 PM on December 31, 2013 [2 favorites]
posted by phaedon at 3:39 PM on December 31, 2013 [2 favorites]
I would have just uploaded a Youtube of me banging my head against the keyboard.
posted by Artw at 3:40 PM on December 31, 2013 [1 favorite]
posted by Artw at 3:40 PM on December 31, 2013 [1 favorite]
This reminded me of a moment from a family vacation we took to the Southwest one summer. We knew we were gonna have to shift time zones from what it was on the East Coast, but we only thought we'd have to change it once. But no.
posted by EmpressCallipygos at 3:42 PM on December 31, 2013 [7 favorites]
* We started in Las Vegas. Pacific time. We all changed our watches accordingly.At one point, my father stopped someone and asked them, "excuse me - what time is it in the exact spot where we're standing right now?"
* Next we drove to Zion Canyon. In Utah. Which we didn't realize, until we got to the park, was on Mountain Time. We changed our watches yet again.
* We then drove to the Grand Canyon. In Arizona. Which we learned was on Mountain Time, so we thought we could leave our watches as-is - but then someone said that Arizona was on Mountain STANDARD time and not Mountain DAYLIGHT time. So we had to change our watches yet again.
* Then we went to Lake Powell, which straddles the Utah/Arizona border. So depending on where we were in the park, we were either on Mountain Standard Time or Mountain Daylight Time.
posted by EmpressCallipygos at 3:42 PM on December 31, 2013 [7 favorites]
Let us not forget the problem of sorting out two computers beliefs about when a thing happened.
posted by wotsac at 3:42 PM on December 31, 2013 [2 favorites]
posted by wotsac at 3:42 PM on December 31, 2013 [2 favorites]
The world began in 1970 and will end in 2038.
Seriously, another of my favorite topics is this idea that the future never comes. One of the reasons IP address exhaustion came sooner than it might have is the fact that application and OS developers somehow believe that it's their responsibility to enforce the "reserved" class of addresses. I got into this fight with QA more than once: they'd put in test plans or file bugs that the user was "allowed" to put in a reserved IP address into a system configuration. I'd invalidate the bug saying "not our job to tell them which 32 bit numbers are okay and which aren't, doesn't belong in our code" and we'd waste scant meeting time having a stupid argument about it instead of something important.
posted by George_Spiggott at 3:44 PM on December 31, 2013
Seriously, another of my favorite topics is this idea that the future never comes. One of the reasons IP address exhaustion came sooner than it might have is the fact that application and OS developers somehow believe that it's their responsibility to enforce the "reserved" class of addresses. I got into this fight with QA more than once: they'd put in test plans or file bugs that the user was "allowed" to put in a reserved IP address into a system configuration. I'd invalidate the bug saying "not our job to tell them which 32 bit numbers are okay and which aren't, doesn't belong in our code" and we'd waste scant meeting time having a stupid argument about it instead of something important.
posted by George_Spiggott at 3:44 PM on December 31, 2013
Let us praise the Kingdom of Morocco, which postponed its transition from summertime by a month this year. The announcement was made on the day before it was originally supposed to happen.
posted by dhoe at 3:56 PM on December 31, 2013 [2 favorites]
posted by dhoe at 3:56 PM on December 31, 2013 [2 favorites]
octothorpe: epoch seconds are more reliable, and less ambiguous, than any common alternative
Sure but when you're trying to compare them to timestamps in other timezones/formats you can get confused in a hurry. I had a script that would take a timestamp in any format/timezone and output the same time in all formats at once.
posted by octothorpe at 3:57 PM on December 31, 2013
Sure but when you're trying to compare them to timestamps in other timezones/formats you can get confused in a hurry. I had a script that would take a timestamp in any format/timezone and output the same time in all formats at once.
posted by octothorpe at 3:57 PM on December 31, 2013
That was a great video. I was working as a business analyst for a large telecom during the first DST switchover after the US changed the DST dates - what was it, six, seven years ago, now? I had helped to write up some schedules and procedures for manning a bridge to work all of the kinks out over the day as the changes rolled out, and then I had a couple of shifts where I also helped to man the bridge. There were half-a-dozen people on my team who didn't sleep much if at all for a couple of days - and none of us even had to do any of the technical stuff. This was just PM logistics for meetings to handle issues. Crazy.
posted by It's Raining Florence Henderson at 3:58 PM on December 31, 2013 [2 favorites]
posted by It's Raining Florence Henderson at 3:58 PM on December 31, 2013 [2 favorites]
sweetkid: "This is what business requirements and use cases are for, so you don't have "'Allo! Samoa CAWLING!""
Ideally, yeah, but I think the reason you hear programmers talk this way is that most of these problems rear their heads during development, when it becomes clear that the requirements aren't even close to a comprehensive accounting of all the issues at hand.
posted by invitapriore at 3:59 PM on December 31, 2013 [6 favorites]
Ideally, yeah, but I think the reason you hear programmers talk this way is that most of these problems rear their heads during development, when it becomes clear that the requirements aren't even close to a comprehensive accounting of all the issues at hand.
posted by invitapriore at 3:59 PM on December 31, 2013 [6 favorites]
Only an idiot would write time to local time conversion using hours as the offset unit. QED the subject of the video is an idiot. Really these are not complicated requirements, just tedious. Fortunately most programming languages have whole libraries where someone else has done the tedious part for you.
posted by humanfont at 3:59 PM on December 31, 2013 [1 favorite]
posted by humanfont at 3:59 PM on December 31, 2013 [1 favorite]
On a positive note, this is something that Video is probably actually a pretty good medium to teach people.
posted by Nanukthedog at 4:00 PM on December 31, 2013
posted by Nanukthedog at 4:00 PM on December 31, 2013
Happy UTC new year, by the way.
posted by idiopath at 4:06 PM on December 31, 2013 [3 favorites]
posted by idiopath at 4:06 PM on December 31, 2013 [3 favorites]
BRING BACK SWATCH TIME
I remember there was this one guy in an IRC channel I frequented who insisted on referring to everything in that because it was more Internet-y.
posted by RonButNotStupid at 4:08 PM on December 31, 2013 [1 favorite]
I remember there was this one guy in an IRC channel I frequented who insisted on referring to everything in that because it was more Internet-y.
posted by RonButNotStupid at 4:08 PM on December 31, 2013 [1 favorite]
Per the link: "Time, technology and leaping seconds."
posted by phaedon at 4:12 PM on December 31, 2013
posted by phaedon at 4:12 PM on December 31, 2013
Time is not a function of location on the planet surface in some particular zone. It is a function of government. Code accordingly and assume that vast swatches of unoccupied ocean are a single compliant entity...
posted by jim in austin at 4:17 PM on December 31, 2013
posted by jim in austin at 4:17 PM on December 31, 2013
I've often wondered what it would take to actually convert from timezones to a standard astronomical or nuclear decay time measuring system.
Also, given that time IS affected by gravity wells, and if I remember correctly, this is why time moves slower at the bottom of the ocean than it does at the top of Mt. Everest (Gravitational Time Dilation). Mind you, I believe on Earth the difference is small, but definitely measurable (and has to be accounted for with GPS systems.
I do wonder if it would be necessary to measure the altitude to adjust for this difference as well (can't seem to find a reference for a defined differential between varying altitudes in the gravitational well).
Time. The more you learn about it, the more you realize how little we understand it.
posted by daq at 4:18 PM on December 31, 2013 [2 favorites]
Also, given that time IS affected by gravity wells, and if I remember correctly, this is why time moves slower at the bottom of the ocean than it does at the top of Mt. Everest (Gravitational Time Dilation). Mind you, I believe on Earth the difference is small, but definitely measurable (and has to be accounted for with GPS systems.
I do wonder if it would be necessary to measure the altitude to adjust for this difference as well (can't seem to find a reference for a defined differential between varying altitudes in the gravitational well).
Time. The more you learn about it, the more you realize how little we understand it.
posted by daq at 4:18 PM on December 31, 2013 [2 favorites]
It's fun to refer to the UNIX structure that stores time information and ask people what they think the permissible range of values for the "seconds" field is.
posted by benito.strauss at 4:32 PM on December 31, 2013 [1 favorite]
posted by benito.strauss at 4:32 PM on December 31, 2013 [1 favorite]
In the early 1800s, some distant but interesting ancestors were among the first American settlers of the southeastern corner of Indiana. Being as close as it was to Cincinnati, this part of the state, including the small town of Vevay, used Cincinnati time—just one more patch in the crazy quilt that was standardized time in Indiana until very recently.
Anyway, because of its idiosyncrasies, Vevay earned a spot in the IANA time zone ("tz") database, an accommodation made at a time when there was unlikely to be more than a few (any?) computers in Vevay to use it. The ongoing consequence of this is that this tiny town of my ancestors still turns up among much more noteworthy conurbations in the context of clocks and computers.
Check it out: on a phone running the most recent version of Android, open up the clock app, select the globe icon (for "world time") from the clock tab, and see what cities are there to choose from. Austin. Jakarta. Madrid. Rome. Vevay.
posted by tss at 4:44 PM on December 31, 2013 [7 favorites]
Anyway, because of its idiosyncrasies, Vevay earned a spot in the IANA time zone ("tz") database, an accommodation made at a time when there was unlikely to be more than a few (any?) computers in Vevay to use it. The ongoing consequence of this is that this tiny town of my ancestors still turns up among much more noteworthy conurbations in the context of clocks and computers.
Check it out: on a phone running the most recent version of Android, open up the clock app, select the globe icon (for "world time") from the clock tab, and see what cities are there to choose from. Austin. Jakarta. Madrid. Rome. Vevay.
posted by tss at 4:44 PM on December 31, 2013 [7 favorites]
Time existed before watches; it even used the same units (hours and minutes) that we do today. The day was divided into twelve hours; so was the night. This meant that the length of an hour shifted with the seasons. These are planetary or temporal hours.
Astronomers knew very well that these hours varied in length, but they used the same term to refer to fractions of the sun's (apparent) path through the sky. These fractions, equivalent to the hours we use today, are sidereal or equinoctal hours.
There was a wholly parallel system of measuring time: distance. Time could be expressed in terms of the distance a typical person could walk in that period. An mile-hour, in this system, was equivalent to a distance of three or four miles. This system made much more sense for people who were not astronomers because it was fairly constant throughout the seasons and you didn't need to use a sextant to measure the sun's height above the horizon. The problem with this system is that it's (a) not very precise; (b) people used different assumptions - a mile-hour could be three or four miles in length; it could be based on an amble or on a military march; and so forth.
These different systems had their place: travellers and most employers needed fixed hours, but it made sense for guards (e.g.) to work for fractions of a day or night. That way you could have a day-captain and a night-captain, and let them allocate resources accordingly. Anyway, the guards' duty periods (called "watches", incidentally) evened up over the course of a year. Astronomers needed to use the uniquely-precise sidereal hours, of course, and it turned out that the benefits of precision were worth the inconvenience of creating and maintaining devices to tell you the sidereal time. And that is why your iPhone has what is conceptually a little solar observatory inside.
posted by Joe in Australia at 4:45 PM on December 31, 2013 [9 favorites]
Astronomers knew very well that these hours varied in length, but they used the same term to refer to fractions of the sun's (apparent) path through the sky. These fractions, equivalent to the hours we use today, are sidereal or equinoctal hours.
There was a wholly parallel system of measuring time: distance. Time could be expressed in terms of the distance a typical person could walk in that period. An mile-hour, in this system, was equivalent to a distance of three or four miles. This system made much more sense for people who were not astronomers because it was fairly constant throughout the seasons and you didn't need to use a sextant to measure the sun's height above the horizon. The problem with this system is that it's (a) not very precise; (b) people used different assumptions - a mile-hour could be three or four miles in length; it could be based on an amble or on a military march; and so forth.
These different systems had their place: travellers and most employers needed fixed hours, but it made sense for guards (e.g.) to work for fractions of a day or night. That way you could have a day-captain and a night-captain, and let them allocate resources accordingly. Anyway, the guards' duty periods (called "watches", incidentally) evened up over the course of a year. Astronomers needed to use the uniquely-precise sidereal hours, of course, and it turned out that the benefits of precision were worth the inconvenience of creating and maintaining devices to tell you the sidereal time. And that is why your iPhone has what is conceptually a little solar observatory inside.
posted by Joe in Australia at 4:45 PM on December 31, 2013 [9 favorites]
0-61... Er...what's that about?
Double leap second.
posted by eddydamascene at 4:48 PM on December 31, 2013 [1 favorite]
Double leap second.
posted by eddydamascene at 4:48 PM on December 31, 2013 [1 favorite]
Also, given that time IS affected by gravity wells, and if I remember correctly, this is why time moves slower at the bottom of the ocean than it does at the top of Mt. Everest
The fact that there's no universal "now" binding everything together into the same moment is one of those things about reality which I find personally upsetting having grown up in a world where seemingly instant communication is ubiquitous. I often idly speculate about what's happening right now on faraway planets and in absurdly distant galaxies and it just seems so weird and isolating to know that there is no "right now" there, at least not any frame of reference I can connect to or communicate with.
posted by RonButNotStupid at 4:54 PM on December 31, 2013 [3 favorites]
The fact that there's no universal "now" binding everything together into the same moment is one of those things about reality which I find personally upsetting having grown up in a world where seemingly instant communication is ubiquitous. I often idly speculate about what's happening right now on faraway planets and in absurdly distant galaxies and it just seems so weird and isolating to know that there is no "right now" there, at least not any frame of reference I can connect to or communicate with.
posted by RonButNotStupid at 4:54 PM on December 31, 2013 [3 favorites]
Artw: This man page says "The range of values for %S is [00,61] rather than [00,59] to allow for the occasional leap second and even more infrequent double leap second."
I should say it is infrequent! there has never been one, and barring a cosmic catastrophe there never will be. Leap seconds are added or (in theory) subtracted to keep clock time within .9 seconds of sidereal time, so you will never have a 62-second minute.
posted by Joe in Australia at 4:56 PM on December 31, 2013 [1 favorite]
I should say it is infrequent! there has never been one, and barring a cosmic catastrophe there never will be. Leap seconds are added or (in theory) subtracted to keep clock time within .9 seconds of sidereal time, so you will never have a 62-second minute.
posted by Joe in Australia at 4:56 PM on December 31, 2013 [1 favorite]
The man is dead on (said another man who lost many hairs and much sanity to this. Several times.)
posted by twidget at 5:01 PM on December 31, 2013 [1 favorite]
posted by twidget at 5:01 PM on December 31, 2013 [1 favorite]
Oh what a pile of crap. Watching this guy's histrionics is like seeing someone discard thousands of years of scholarship. The passage of time is the fundamental mathematical concept that has fueled the development of mankind, from near-apes looking at the sun move through the sky, through modern scholars measuring relativistic time differences between satellites.
This stuff has all been worked out for ages. Want to know about time? Ask an astrologer. That's where the TZ time zone database came from, they collected all the historical data of what areas were in different time zones and when they were in DST. Astrologers invented stuff like ephemerides and calendars and clocks. They invented the Julian calendar, and the Gregorian calendar. They're the ones who calculated abstruse timekeeping systems throughout history like the Japanese clock with variable hour lengths.
I have a sense of profound sadness, seeing a supposedly educated "computerphile" who expresses bafflement at problems that would be considered simple by a 17th century astrologer. Time keeps passing regardless of the methods used to record it. Once you understand this, everything is simple.
posted by charlie don't surf at 5:03 PM on December 31, 2013 [1 favorite]
This stuff has all been worked out for ages. Want to know about time? Ask an astrologer. That's where the TZ time zone database came from, they collected all the historical data of what areas were in different time zones and when they were in DST. Astrologers invented stuff like ephemerides and calendars and clocks. They invented the Julian calendar, and the Gregorian calendar. They're the ones who calculated abstruse timekeeping systems throughout history like the Japanese clock with variable hour lengths.
I have a sense of profound sadness, seeing a supposedly educated "computerphile" who expresses bafflement at problems that would be considered simple by a 17th century astrologer. Time keeps passing regardless of the methods used to record it. Once you understand this, everything is simple.
posted by charlie don't surf at 5:03 PM on December 31, 2013 [1 favorite]
BRING BACK SWATCH TIME
I ALREADY DID
also worth noting: the person who developed the French Revolutionary Calendar was actually beheaded for their crimes
posted by phooky at 5:08 PM on December 31, 2013 [3 favorites]
I ALREADY DID
also worth noting: the person who developed the French Revolutionary Calendar was actually beheaded for their crimes
posted by phooky at 5:08 PM on December 31, 2013 [3 favorites]
More interesting is calculating "now" in real time MMOPRG and FPS games where users may be experiencing differing degrees of lag, computer processing power and locally affecting different parts of the map vs. world features and connecting through different servers. This paper goes into some detail on various strategies around this
posted by humanfont at 5:21 PM on December 31, 2013 [1 favorite]
posted by humanfont at 5:21 PM on December 31, 2013 [1 favorite]
If you think its bad now, just wait until they decouple earth's rotation from the computation of time.
posted by Dr. Twist at 5:29 PM on December 31, 2013 [1 favorite]
posted by Dr. Twist at 5:29 PM on December 31, 2013 [1 favorite]
charlie don't surf: I think you're profoundly missing the point here. The programmer here isn't the one making things more complicated than they need to be. He's just trying to deal with the complexity and inconsistency that's already in place in time-and-date formats produced throughout the world, and throughout history.
Yes, you can use a nice simple consistent time system internally. (As the video says, you're insane if you don't.) But if you're inputting timestamps from documents originating in England during the 1940s, your program to convert those timestamps to your internal format had better know about double daylight savings time, or it's going to get them wrong. How is a 17th-century astrologer going to help you with problems like that? By having a sharp word with Churchill on the way back to the 17th century?
posted by baf at 5:38 PM on December 31, 2013 [15 favorites]
Yes, you can use a nice simple consistent time system internally. (As the video says, you're insane if you don't.) But if you're inputting timestamps from documents originating in England during the 1940s, your program to convert those timestamps to your internal format had better know about double daylight savings time, or it's going to get them wrong. How is a 17th-century astrologer going to help you with problems like that? By having a sharp word with Churchill on the way back to the 17th century?
posted by baf at 5:38 PM on December 31, 2013 [15 favorites]
A lot of big multiprocessor systems have nonmonotonic clocks. You can take the time at A, take the time later at B, subtract B-A, and get a negative number because your process was switched to a different node with a slightly out-of-sync clock. This has been known to drive programmers mad.
posted by miyabo at 5:40 PM on December 31, 2013 [3 favorites]
posted by miyabo at 5:40 PM on December 31, 2013 [3 favorites]
I don't think he gives enough credit to the Unix epoch seconds approach. It works very well because it decouples the two things people often conflate: 1: Time, which is universal (barring relativistic effects) and 2: The numerous ways of representing time, which are not.
The first is easy for a computer. There are issues when adjusting a clock that is incorrect, but that is minor compared to the second thing...
The second has been handled by Arthur David Olsen and Paul Eggert. They have suffered exactly the pain described in the video, and they have suffered it fully. It is by their sacrifice that we are able to convert the blessed time_t to and from the abomination that is "local time".
posted by swr at 5:43 PM on December 31, 2013 [3 favorites]
The first is easy for a computer. There are issues when adjusting a clock that is incorrect, but that is minor compared to the second thing...
The second has been handled by Arthur David Olsen and Paul Eggert. They have suffered exactly the pain described in the video, and they have suffered it fully. It is by their sacrifice that we are able to convert the blessed time_t to and from the abomination that is "local time".
posted by swr at 5:43 PM on December 31, 2013 [3 favorites]
Cory Doctrow's Martian Chronicles raised the problem of Mars time... EPOCH would probably just work for that too.
posted by Artw at 5:46 PM on December 31, 2013
posted by Artw at 5:46 PM on December 31, 2013
This stuff has all been worked out for ages.
You don't understand what you're talking about here. Time on computers is a capital-H hard problem. As far as programs are concerned, it doesn't necessarily move forward at the same rate on different systems - sometimes dramatically so - and can occasionally even move backwards. Not because Time does that, but because system clocks do.
We've already seen Falsehoods Programmers Believe About Time in the blue, I think, but I want you to believe me when I say that unless you've worked in a widely distributed and heterogeneous environment dependent during a legislatively-mandated change in the Daylight Savings schedule, you probably don't appreciate the magnitude of the problem here.
posted by mhoye at 5:49 PM on December 31, 2013 [4 favorites]
You don't understand what you're talking about here. Time on computers is a capital-H hard problem. As far as programs are concerned, it doesn't necessarily move forward at the same rate on different systems - sometimes dramatically so - and can occasionally even move backwards. Not because Time does that, but because system clocks do.
We've already seen Falsehoods Programmers Believe About Time in the blue, I think, but I want you to believe me when I say that unless you've worked in a widely distributed and heterogeneous environment dependent during a legislatively-mandated change in the Daylight Savings schedule, you probably don't appreciate the magnitude of the problem here.
posted by mhoye at 5:49 PM on December 31, 2013 [4 favorites]
I have a sense of profound sadness, seeing a supposedly educated "computerphile" who expresses bafflement at problems that would be considered simple by a 17th century astrologer. Time keeps passing regardless of the methods used to record it. Once you understand this, everything is simple.
I'm kind of skeptical that a 17th-century astrologer would really have a good grasp of the implications of realtime communication across the globe involving clocks that are in different time zones and consequently on different calendar days in many cases.
posted by XMLicious at 5:51 PM on December 31, 2013 [1 favorite]
I'm kind of skeptical that a 17th-century astrologer would really have a good grasp of the implications of realtime communication across the globe involving clocks that are in different time zones and consequently on different calendar days in many cases.
Our 17th century astrologer has his own problems! That poor guy is is right in the middle of a centuries-long transition from the Julian to the Gregorian calendar, where countries were dropping ten to thirteen pretty arbitrary days on the floor to line up with each other, one country at a time. If our 17th century astrologer agrees to meet somebody in a foreign land on the tenth day of the tenth month in major port city, well, when is that exactly? Depends on where they are, where their meeting is, what country the counterparty is from, and maybe even where they agreed to the meeting. He doesn't have it easy!
And that is just a taste of how hard this problem is.
(That's one of the gags in Eco's brilliant Foucault's Pendulum, incidentally.)
posted by mhoye at 6:02 PM on December 31, 2013 [11 favorites]
Our 17th century astrologer has his own problems! That poor guy is is right in the middle of a centuries-long transition from the Julian to the Gregorian calendar, where countries were dropping ten to thirteen pretty arbitrary days on the floor to line up with each other, one country at a time. If our 17th century astrologer agrees to meet somebody in a foreign land on the tenth day of the tenth month in major port city, well, when is that exactly? Depends on where they are, where their meeting is, what country the counterparty is from, and maybe even where they agreed to the meeting. He doesn't have it easy!
And that is just a taste of how hard this problem is.
(That's one of the gags in Eco's brilliant Foucault's Pendulum, incidentally.)
posted by mhoye at 6:02 PM on December 31, 2013 [11 favorites]
Being as close as it was to Cincinnati, this part of the state, including the small town of Vevay, used Cincinnati time
was that standard time or railroad time?
(our heroic programmer, already tearing his hair out over the variations of indiana time, goes mad when he realizes that many towns in 19th century america had their own local "railroad" time)
posted by pyramid termite at 6:27 PM on December 31, 2013 [1 favorite]
was that standard time or railroad time?
(our heroic programmer, already tearing his hair out over the variations of indiana time, goes mad when he realizes that many towns in 19th century america had their own local "railroad" time)
posted by pyramid termite at 6:27 PM on December 31, 2013 [1 favorite]
The development team I joined at my current company has implemented a standard procedure to deal with this type of issue. It follows a single unconditional rule:
Count the number of times you say Time Zone or Daylight Savings when describing a feature. Call that the number x.
When we are done listening to you, we will not deliver the feature until we are given x cases of beer.
And so, on calls regarding new features where time is involved, developers may seem to say at random: "case of beer".
we want it and say it, but the delivery rate is less than desired
posted by timfinnie at 6:32 PM on December 31, 2013 [7 favorites]
Count the number of times you say Time Zone or Daylight Savings when describing a feature. Call that the number x.
When we are done listening to you, we will not deliver the feature until we are given x cases of beer.
And so, on calls regarding new features where time is involved, developers may seem to say at random: "case of beer".
we want it and say it, but the delivery rate is less than desired
posted by timfinnie at 6:32 PM on December 31, 2013 [7 favorites]
a centuries-long transition from the Julian to the Gregorian calendar
This didn't happen in Russia until 1917.
posted by thelonius at 6:34 PM on December 31, 2013 [1 favorite]
This didn't happen in Russia until 1917.
posted by thelonius at 6:34 PM on December 31, 2013 [1 favorite]
The second has been handled by Arthur David Olsen and Paul Eggert. They have suffered exactly the pain described in the video, and they have suffered it fully. It is by their sacrifice that we are able to convert the blessed time_t to and from the abomination that is "local time".
Right, they solved the problem by consulting an astrological reference book, and copying the ACS database, as I previously mentioned. This resulted in a significant copyright lawsuit, which IMHO was righteous and ACS should not have given up. While facts like time zones and DST durations are not copyrightable, their formatting in a database or ephemeris IS copyrightable, and bulk copying it into the TZ database without licensing was reprehensible.
Yes, you can use a nice simple consistent time system internally. (As the video says, you're insane if you don't.) But if you're inputting timestamps from documents originating in England during the 1940s, your program to convert those timestamps to your internal format had better know about double daylight savings time, or it's going to get them wrong.
I have done this. I consulted the ACS database.
I'm kind of skeptical that a 17th-century astrologer would really have a good grasp of the implications of realtime communication across the globe involving clocks that are in different time zones and consequently on different calendar days in many cases.
Quite the contrary. An astrologer would have no difficulty in conceptualizing simultaneous events at different locations on the globe, according to an arbitrary, impartial standard like celestial events. Eratosthenes covered that in about 200BC.
(our heroic programmer, already tearing his hair out over the variations of indiana time, goes mad when he realizes that many towns in 19th century america had their own local "railroad" time)
Which is linked to Local Noon and easily derived from Sidereal Time.
posted by charlie don't surf at 6:35 PM on December 31, 2013 [1 favorite]
Right, they solved the problem by consulting an astrological reference book, and copying the ACS database, as I previously mentioned. This resulted in a significant copyright lawsuit, which IMHO was righteous and ACS should not have given up. While facts like time zones and DST durations are not copyrightable, their formatting in a database or ephemeris IS copyrightable, and bulk copying it into the TZ database without licensing was reprehensible.
Yes, you can use a nice simple consistent time system internally. (As the video says, you're insane if you don't.) But if you're inputting timestamps from documents originating in England during the 1940s, your program to convert those timestamps to your internal format had better know about double daylight savings time, or it's going to get them wrong.
I have done this. I consulted the ACS database.
I'm kind of skeptical that a 17th-century astrologer would really have a good grasp of the implications of realtime communication across the globe involving clocks that are in different time zones and consequently on different calendar days in many cases.
Quite the contrary. An astrologer would have no difficulty in conceptualizing simultaneous events at different locations on the globe, according to an arbitrary, impartial standard like celestial events. Eratosthenes covered that in about 200BC.
(our heroic programmer, already tearing his hair out over the variations of indiana time, goes mad when he realizes that many towns in 19th century america had their own local "railroad" time)
Which is linked to Local Noon and easily derived from Sidereal Time.
posted by charlie don't surf at 6:35 PM on December 31, 2013 [1 favorite]
I live very close to the Allegheny Observatory in what's now Pittsburgh which sold a time service to the railroads and then used the money to fund their astronomy research. It ran over telegraph lines like a steampunk NTP service.
posted by octothorpe at 7:30 PM on December 31, 2013 [1 favorite]
posted by octothorpe at 7:30 PM on December 31, 2013 [1 favorite]
An astrologer would have no difficulty in conceptualizing simultaneous events at different locations on the globe, according to an arbitrary, impartial standard like celestial events.
I think an astrologer would also probably know that staring at a mechanical clock and conceptualizing at it really hard would not fix any synchronization or timing problems with it, much less if it was part of a global network of not-quite-instantaneously-communicating clocks that didn't follow the same rules but had to constantly and automatically reconcile their readings and records with each other.
If a 16th century astrologer could make a Youtube video about trying to develop orreries or planetarium mechanisms, or contemporary clocks for that matter, he or she would speak with equal exasperation about the intricacies of getting the gearing right and other practical matters. Contemptuously reciting historical background instead would not sound any more erudite or more mechanophile.
posted by XMLicious at 8:02 PM on December 31, 2013 [1 favorite]
The Babylonians had a base 60 number system. Alexander the Great's army conquered the Babylonians and had their astronomical work sent to Aristotle. The Greek astronomer Hipparchus borrowed the Babylonian concept of a circle of 360 degrees divided into 60 parts (arc minutes) each of which is divided into 60 parts (arc seconds).
Sometime in the 16th century we had round, mechanical clocks with pendulums that could measure time more precisely than hours. A minute hand was created and the base 60 system with minutes and seconds was applied to these clocks, and therefore to time.
posted by eye of newt at 9:19 PM on December 31, 2013 [3 favorites]
Sometime in the 16th century we had round, mechanical clocks with pendulums that could measure time more precisely than hours. A minute hand was created and the base 60 system with minutes and seconds was applied to these clocks, and therefore to time.
posted by eye of newt at 9:19 PM on December 31, 2013 [3 favorites]
I have done this. I consulted the ACS database.
Then congratulations: you have done exactly as the video ultimately recommends and let someone else cope with the hideous complexity for you. Except that instead of experiencing gratitude that you're able to do this, as the video recommends, you seem to want to pretend that the fact that someone else is dealing with the complexity means that it isn't there, and that the narrator's attempt at explaining just how good you have it is somehow pitiable.
posted by baf at 9:30 PM on December 31, 2013 [16 favorites]
Then congratulations: you have done exactly as the video ultimately recommends and let someone else cope with the hideous complexity for you. Except that instead of experiencing gratitude that you're able to do this, as the video recommends, you seem to want to pretend that the fact that someone else is dealing with the complexity means that it isn't there, and that the narrator's attempt at explaining just how good you have it is somehow pitiable.
posted by baf at 9:30 PM on December 31, 2013 [16 favorites]
Friends don't let friends write date-handling code.
posted by Lazlo Nibble at 10:25 PM on December 31, 2013 [3 favorites]
posted by Lazlo Nibble at 10:25 PM on December 31, 2013 [3 favorites]
was that standard time or railroad time?
Vevay was the kind of place where you got your goods to market by flagging down a packet steamboat. As best I can tell, the only railroad that ever ran through Vevay was the Underground Railroad.
I don't know the answer to this question for sure, but in the postwar era (and likely for decades prior) it probably did whatever Cincinnati saw fit to do with regard to standardized time.
posted by tss at 11:53 PM on December 31, 2013
Vevay was the kind of place where you got your goods to market by flagging down a packet steamboat. As best I can tell, the only railroad that ever ran through Vevay was the Underground Railroad.
I don't know the answer to this question for sure, but in the postwar era (and likely for decades prior) it probably did whatever Cincinnati saw fit to do with regard to standardized time.
posted by tss at 11:53 PM on December 31, 2013
The one historical thing I'm sad he didn't get to was the fact that revolutionary France decided that time was insufficiently rational, and moved to the Republican French Calendar, which, starting on September 22nd, 1792:
It would have been much more elegant and rational to have made each decimal day 87.658128 traditional hours long.
It would take a bit of adjusting, certainly. But once we switch over, everything's so much more tidy and straightforward.
posted by sebastienbailard at 1:46 AM on January 1, 2014
It would have been much more elegant and rational to have made each decimal day 87.658128 traditional hours long.
It would take a bit of adjusting, certainly. But once we switch over, everything's so much more tidy and straightforward.
posted by sebastienbailard at 1:46 AM on January 1, 2014
The presenter sounds slightly uncomfortable, like there is a freshly-dead cat just off-camera.
posted by Quilford at 2:35 AM on January 1, 2014 [2 favorites]
posted by Quilford at 2:35 AM on January 1, 2014 [2 favorites]
Your server should never, ever see a date that is not your single standard -- typically UTC for most ordinary uses. Really, time conversions should only be done at presentation time, at the user-facing i/o level and nowhere else.
That's the common wisdom, but it's incorrect. Suppose I'm writing a program that keeps track of appointments. I enter the date and time of my dentist appointment which is 6 months in the future. Your program immediately converts that to a UTC epoch time and stores that value, discarding the local time that I entered. But suppose in 3 months from now my local government decides to move the beginning or ending of daylight savings forward or backward by a week, and suppose that my appointment falls in the affected week. Now your stored UTC epoch timestamp is wrong by an hour, causing me to miss my appointment.
The problem is that by immediately converting to UTC on intake, you hard-code the Olson database rules as they existed at the time, but those rules are subject to change between now and then. What you must do is store the date and time as I entered it in local time, along with the identifier of the time zone that I've selected. You can still continue to also generate a UTC epoch timestamp, but you must treat it as a cached value that must be regenerated every time you install a new version of the Olson DB. And that's only possible if you held on to the time and date in local time and the name of the timezone.
posted by Rhomboid at 3:23 AM on January 1, 2014 [15 favorites]
That's the common wisdom, but it's incorrect. Suppose I'm writing a program that keeps track of appointments. I enter the date and time of my dentist appointment which is 6 months in the future. Your program immediately converts that to a UTC epoch time and stores that value, discarding the local time that I entered. But suppose in 3 months from now my local government decides to move the beginning or ending of daylight savings forward or backward by a week, and suppose that my appointment falls in the affected week. Now your stored UTC epoch timestamp is wrong by an hour, causing me to miss my appointment.
The problem is that by immediately converting to UTC on intake, you hard-code the Olson database rules as they existed at the time, but those rules are subject to change between now and then. What you must do is store the date and time as I entered it in local time, along with the identifier of the time zone that I've selected. You can still continue to also generate a UTC epoch timestamp, but you must treat it as a cached value that must be regenerated every time you install a new version of the Olson DB. And that's only possible if you held on to the time and date in local time and the name of the timezone.
posted by Rhomboid at 3:23 AM on January 1, 2014 [15 favorites]
I once thought I'd simply the user interface for timezone selection in GNOME. In fact, if you go to the world map that's in GNOME's location picker today, I made that, and it looks a lot better than what was there before, so that's a good thing that came out of it, I guess. But originally, I was going to do a set of overlays to indicate timezones graphically, and you'd just roughly click on your location and you'd get the right one, and... you see where this is going. I ran into basically the same thing that they're talking about in the video, and all we got was a prettier map.
posted by Joakim Ziegler at 6:22 AM on January 1, 2014 [2 favorites]
posted by Joakim Ziegler at 6:22 AM on January 1, 2014 [2 favorites]
I enter the date and time of my dentist appointment which is 6 months in the future. Your program immediately converts that to a UTC epoch time and stores that value, discarding the local time that I entered. But suppose in 3 months from now my local government decides to move the beginning or ending of daylight savings forward or backward by a week, and suppose that my appointment falls in the affected week. Now your stored UTC epoch timestamp is wrong by an hour, causing me to miss my appointment.
Another one is entering a travel itinerary into a calendar. You may enter outbound and return flights into your calendar while sitting in the same time zone as your local airport, but the return flight departure time is based on the time zone of the other airport. If you convert the local wall time to epoch seconds using the timezone you're in when entering things into the calendar, then switch your calendar software to use the local timezone when you arrive at the destination, the return flight time will suddenly be off by the difference between the two timezones. The stored timestamp was always incorrect, but it doesn't become obvious until you switch to the other timezone.
This is an example of the conflation I mentioned earlier. Sometimes you care about the physical phenomenon of time and its passage, other times you care about where the big hand and little hand will be on the face of some clock somewhere. They are two different problems, and by conflating them, people can end up solving the wrong one.
posted by swr at 7:00 AM on January 1, 2014 [2 favorites]
Another one is entering a travel itinerary into a calendar. You may enter outbound and return flights into your calendar while sitting in the same time zone as your local airport, but the return flight departure time is based on the time zone of the other airport. If you convert the local wall time to epoch seconds using the timezone you're in when entering things into the calendar, then switch your calendar software to use the local timezone when you arrive at the destination, the return flight time will suddenly be off by the difference between the two timezones. The stored timestamp was always incorrect, but it doesn't become obvious until you switch to the other timezone.
This is an example of the conflation I mentioned earlier. Sometimes you care about the physical phenomenon of time and its passage, other times you care about where the big hand and little hand will be on the face of some clock somewhere. They are two different problems, and by conflating them, people can end up solving the wrong one.
posted by swr at 7:00 AM on January 1, 2014 [2 favorites]
Raymond Chen tells the story of why the fancy timezone picker map in Windows 95 didn't work out for entirely different but equally exasperating reasons.
posted by Rhomboid at 7:13 AM on January 1, 2014
posted by Rhomboid at 7:13 AM on January 1, 2014
When computers rule the Earth, will Changing Times call for One Time Zone for the World?
posted by cenoxo at 7:34 AM on January 1, 2014 [1 favorite]
posted by cenoxo at 7:34 AM on January 1, 2014 [1 favorite]
I don't think he gives enough credit to the Unix epoch seconds approach. It works very well
...except it doesn't deal with leap seconds, because the way Posix time is defined says that each day has exactly 86,400 seconds and if you don't like that then fuck you.
The standard way of dealing with this involves breaking the clock's monotonicity, and actually deleting or repeating seconds during leap second adjustments. This is obviously hideous and for a while there it was actually causing Linux boxes (including my school virtual machine host, to my chagrin) to lock up.
Google came up with a workaround for it that they called the leap smear, which preserves monotonicity but distorts the durations of seconds in order to sweep the adjustment under the rug.
A sane computer timekeeping system would just use GPS time or TAI and not make assumptions about there being 86,400 seconds in every single day. But Posix time doesn't do that, and Posix time is everywhere so we're pretty much stuck with it.
Windows time is even worse; it has no provision for dealing with leap seconds at all and just flat ignores the whole phenomenon.
All of which means that the job of calculating the number of seconds between two arbitrary calendar dates and times is, in practice, ridiculously more difficult that it ought to be even given tzdata.
posted by flabdablet at 7:36 AM on January 1, 2014 [1 favorite]
...except it doesn't deal with leap seconds, because the way Posix time is defined says that each day has exactly 86,400 seconds and if you don't like that then fuck you.
The standard way of dealing with this involves breaking the clock's monotonicity, and actually deleting or repeating seconds during leap second adjustments. This is obviously hideous and for a while there it was actually causing Linux boxes (including my school virtual machine host, to my chagrin) to lock up.
Google came up with a workaround for it that they called the leap smear, which preserves monotonicity but distorts the durations of seconds in order to sweep the adjustment under the rug.
A sane computer timekeeping system would just use GPS time or TAI and not make assumptions about there being 86,400 seconds in every single day. But Posix time doesn't do that, and Posix time is everywhere so we're pretty much stuck with it.
Windows time is even worse; it has no provision for dealing with leap seconds at all and just flat ignores the whole phenomenon.
All of which means that the job of calculating the number of seconds between two arbitrary calendar dates and times is, in practice, ridiculously more difficult that it ought to be even given tzdata.
posted by flabdablet at 7:36 AM on January 1, 2014 [1 favorite]
The Tyranny of the Clock, George Woodcock, March 1944:
posted by cenoxo at 8:13 AM on January 1, 2014 [2 favorites]
Modern, Western man, however lives in a world which runs according to the mechanical and mathematical symbols of clock time. The clock dictates his movements and inhibits his actions. The clock turns time from a process of nature into a commodity that can be measured and bought and sold like soap or sultanas. And because, without some means of exact time keeping, industrial capitalism could never have developed and could not continue to exploit the workers, the clock represents an element of mechanical tyranny in the lives of modern men more potent than any individual exploiter or any other machine.What happens if computers are employed by the right people?
posted by cenoxo at 8:13 AM on January 1, 2014 [2 favorites]
RonButNotStupid: The fact that there's no universal "now" binding everything together into the same moment is one of those things about reality which I find personally upsetting having grown up in a world where seemingly instant communication is ubiquitous. I often idly speculate about what's happening right now on faraway planets and in absurdly distant galaxies and it just seems so weird and isolating to know that there is no "right now" there, at least not any frame of reference I can connect to or communicate with.The idea of "now" is one closely linked to "here", so in a similar fashion there is no such thing as an indisputable "here" (or "there"). The less "here" you have the more "now" you get (the smaller the locale the more "simultaneity" can be "asserted"). Which is basically a way of saying that the more information you have about when something happened, the less information you have about where something happened.
And vice versa.
It's all good.
posted by mistersquid at 10:48 AM on January 1, 2014
Do you know how many time zones there are in the Soviet Union?
posted by fungible at 10:51 AM on January 1, 2014
posted by fungible at 10:51 AM on January 1, 2014
So tell us, how many? America is waiting.
posted by benito.strauss at 10:53 AM on January 1, 2014
posted by benito.strauss at 10:53 AM on January 1, 2014
It's 2014. There are no time zones in the Soviet Union.
posted by George_Spiggott at 11:10 AM on January 1, 2014 [3 favorites]
posted by George_Spiggott at 11:10 AM on January 1, 2014 [3 favorites]
From cenoxo's One Time Zone for the World link:
In 2010, Russia abolished two of its time zones, dropping the number from 11 to nine. And Russian President Dmitry Medvedev has suggested he may prune more zones in the future.posted by Rhomboid at 12:12 PM on January 1, 2014
The US, counting only the 50 states but including the Aleutians would easily span 9 time zones if we didn't jigger it a lot.. Alaska alone would fall into 4 if we let it, but as it stands we stick most of it in just one.
posted by George_Spiggott at 12:25 PM on January 1, 2014 [1 favorite]
posted by George_Spiggott at 12:25 PM on January 1, 2014 [1 favorite]
Alaska alone would fall into 4 if we let it, but as it stands we stick most of it in just one.
The North in general is like that; time zones narrow towards the poles. But the North has a very odd relationship with time. There's not much point being picky about the exact hour when coarser distinctions like "night" and "day" are so fuzzy.
That said, Nunavut crosses three time zones (and weirdly, at that), so, hey.
posted by Sys Rq at 1:04 PM on January 1, 2014 [1 favorite]
The North in general is like that; time zones narrow towards the poles. But the North has a very odd relationship with time. There's not much point being picky about the exact hour when coarser distinctions like "night" and "day" are so fuzzy.
That said, Nunavut crosses three time zones (and weirdly, at that), so, hey.
posted by Sys Rq at 1:04 PM on January 1, 2014 [1 favorite]
But the North has a very odd relationship with time.
But on the other hand, the North does have a good relationship with memory...
posted by Rhomboid at 2:18 PM on January 1, 2014 [1 favorite]
But on the other hand, the North does have a good relationship with memory...
posted by Rhomboid at 2:18 PM on January 1, 2014 [1 favorite]
Previously: What time zone is the South Pole? Ever wonder how time zones work at the North and South Poles?
posted by cenoxo at 2:36 PM on January 1, 2014 [1 favorite]
posted by cenoxo at 2:36 PM on January 1, 2014 [1 favorite]
charlie don't surf:
So if you think this is so easy, here's a not so arbitrary example. I have a truck that runs night shift, 7 days a week, and every day at 1:30am I need to check where that truck is. If it's not at the right place, the driver gets a mark on their record. Two days a year, what happens?
Yeah the issue is obvious because of the context I've given, but things like this happen ALL over the place. And in ugly ass ways. Doubly so in distributed systems where you might be dealing with computers that don't have the latest tzinfo and disagree about what time it is. Of course they only disagree one week out of the year, and only for a few countries, so it never gets noticed until all hell breaks loose in the Brazilian office and FUCK YOU TIME DIE DIE DIE.
Every programmer goes through phases of understanding how much of a pain in the ass time can be. Some never get past the naive "what does the clock say?" phase, some never get past the almost as naive "just use unix time and convert."
posted by aspo at 2:59 PM on January 1, 2014 [4 favorites]
So if you think this is so easy, here's a not so arbitrary example. I have a truck that runs night shift, 7 days a week, and every day at 1:30am I need to check where that truck is. If it's not at the right place, the driver gets a mark on their record. Two days a year, what happens?
Yeah the issue is obvious because of the context I've given, but things like this happen ALL over the place. And in ugly ass ways. Doubly so in distributed systems where you might be dealing with computers that don't have the latest tzinfo and disagree about what time it is. Of course they only disagree one week out of the year, and only for a few countries, so it never gets noticed until all hell breaks loose in the Brazilian office and FUCK YOU TIME DIE DIE DIE.
Every programmer goes through phases of understanding how much of a pain in the ass time can be. Some never get past the naive "what does the clock say?" phase, some never get past the almost as naive "just use unix time and convert."
posted by aspo at 2:59 PM on January 1, 2014 [4 favorites]
"what does the clock say?"
Ring-ding-ding-ding-dingeringeding!
Gering-ding-ding-ding-dingeringeding!
Gering-ding-ding-ding-dingeringeding!
posted by tilde at 3:47 PM on January 1, 2014 [4 favorites]
Ring-ding-ding-ding-dingeringeding!
Gering-ding-ding-ding-dingeringeding!
Gering-ding-ding-ding-dingeringeding!
posted by tilde at 3:47 PM on January 1, 2014 [4 favorites]
"what does the clock say?"
Ring-ding-ding-ding-dingeringeding!
Gering-ding-ding-ding-dingeringeding!
Gering-ding-ding-ding-dingeringeding!
bananaphone!
posted by LiteOpera at 8:12 PM on January 1, 2014
Generally you might think it makes sense to store times of things that have already happened in UTC, and times of things that are yet to happen in local time + tz (and the tz has to be stored as a name, not as a numeric offset from UTC, because otherwise you might as well just store the UTC).
But even that doesn't work properly, because tz names change depending on whether or not daylight saving is in effect. So now you're right back into the twisty little maze of arbitrary decisions: if I've stored a time as PDT but PST is in effect by the time the stored time is reached, do I just re-interpret the time as if it were stored as PST? Do I need to issue reminders, on the day of the PDT->PST transition, that some stored future time has just jumped by an hour? Might be best to store an expected UTC time as well, and check on daylight saving transitions whether any of my stored future times have actually changed... and so it goes.
Sometimes you care about the physical phenomenon of time and its passage, other times you care about where the big hand and little hand will be on the face of some clock somewhere. They are two different problems, and by conflating them, people can end up solving the wrong one.
...or neither.
Time programming is hard. And one of the things that makes it extra hard is that it looks easy, which means customers specifying software behaviour will typically have no idea about which of those two problems they want the system to solve or even that they are different.
The fact that the Posix day is always 86,400 Posix seconds is a reflection of this. The only reason the Posix committee didn't specify it properly is for fear of breaking countless thousands of existing business systems that relied on what was, before leap seconds were introduced in 1972, a hard and fast rule - and to buggery with all the scientific systems that made the obviously unreasonable assumption that any given second is exactly as long as any other.
posted by flabdablet at 8:33 PM on January 1, 2014 [1 favorite]
But even that doesn't work properly, because tz names change depending on whether or not daylight saving is in effect. So now you're right back into the twisty little maze of arbitrary decisions: if I've stored a time as PDT but PST is in effect by the time the stored time is reached, do I just re-interpret the time as if it were stored as PST? Do I need to issue reminders, on the day of the PDT->PST transition, that some stored future time has just jumped by an hour? Might be best to store an expected UTC time as well, and check on daylight saving transitions whether any of my stored future times have actually changed... and so it goes.
Sometimes you care about the physical phenomenon of time and its passage, other times you care about where the big hand and little hand will be on the face of some clock somewhere. They are two different problems, and by conflating them, people can end up solving the wrong one.
...or neither.
Time programming is hard. And one of the things that makes it extra hard is that it looks easy, which means customers specifying software behaviour will typically have no idea about which of those two problems they want the system to solve or even that they are different.
The fact that the Posix day is always 86,400 Posix seconds is a reflection of this. The only reason the Posix committee didn't specify it properly is for fear of breaking countless thousands of existing business systems that relied on what was, before leap seconds were introduced in 1972, a hard and fast rule - and to buggery with all the scientific systems that made the obviously unreasonable assumption that any given second is exactly as long as any other.
posted by flabdablet at 8:33 PM on January 1, 2014 [1 favorite]
I have a truck that runs night shift, 7 days a week, and every day at 1:30am I need to check where that truck is. If it's not at the right place, the driver gets a mark on their record.
Is this a fixed location where the truck needs to be? Get the driver a Watchclock and stations to check in at 1:30.
It never ceases to amaze me how people always want complex technological solutions to simple problems.
posted by charlie don't surf at 8:37 PM on January 1, 2014
Is this a fixed location where the truck needs to be? Get the driver a Watchclock and stations to check in at 1:30.
It never ceases to amaze me how people always want complex technological solutions to simple problems.
posted by charlie don't surf at 8:37 PM on January 1, 2014
It never ceases to amaze me how willing otherwise intelligent people are to handwave away genuine complexity on the grounds that the solution to some obvious non-edge-case problem is obvious.
posted by flabdablet at 9:33 PM on January 1, 2014 [6 favorites]
posted by flabdablet at 9:33 PM on January 1, 2014 [6 favorites]
This reminded me of a moment from a family vacation we took to the Southwest one summer. We knew we were gonna have to shift time zones from what it was on the East Coast, but we only thought we'd have to change it once.
I was talking with someone working at Lake Powell. Evidently they have to make sure everyone understands what "10 AM" means since the employees and suppliers may be in AZ, UT, or a Reservation.
posted by bongo_x at 9:46 PM on January 1, 2014
I was talking with someone working at Lake Powell. Evidently they have to make sure everyone understands what "10 AM" means since the employees and suppliers may be in AZ, UT, or a Reservation.
posted by bongo_x at 9:46 PM on January 1, 2014
Is this a fixed location where the truck needs to be? Get the driver a Watchclock and stations to check in at 1:30.
It never ceases to amaze me how people always want complex technological solutions to simple problems.
Unless I'm misunderstanding something in the description on that page, this is a perfect example of what we're talking about. Look at the picture of the "recording strip chart" at the bottom.
If I'm interpreting this properly that's a blank, unused one. But go ahead and randomly put a few timing marks in.
Now tell us the date and time that each mark represents and whether that particular strip contains data from an 11-hour, 12-hour, or 13-hour time span due to a daylight savings time change in the middle of it. Next, write a computer program to perform that interpretation automatically on any recording strip chart that is fed into it. Furthermore, here's a video with its own timestamp running in the corner which shows a watchman stopping in the street outside a station; the police need to confirm with absolute certainty which mark on which strip corresponds to that incident.
You can't accomplish any of those tasks, because your simple solution never recorded the requisite information in the first place. But it's too late; all you have is a pile of ambiguous records now, without any means to reconcile them.
posted by XMLicious at 9:52 PM on January 1, 2014 [4 favorites]
To be fair, those watchclocks were designed before the mind-boggling insanity that is Daylight Saving Time was even a drool on the chin of the sadistic lunatic who invented it. To update them to today's conditions you'd need to supply 11, 12 and 13-hour recording strips and institute harsh punishments for users who failed to fit the correct strip on the correct day.
posted by flabdablet at 3:03 AM on January 2, 2014
posted by flabdablet at 3:03 AM on January 2, 2014
And then you get a call from the astrophysicist who says, by the way, we just had a leap second.
Welcome to my world.
Yes, that way lies madness.
posted by RedOrGreen at 9:25 AM on January 2, 2014
Welcome to my world.
Yes, that way lies madness.
posted by RedOrGreen at 9:25 AM on January 2, 2014
Why get so worried over such ephemeral concerns?
posted by benito.strauss at 9:38 AM on January 2, 2014 [2 favorites]
posted by benito.strauss at 9:38 AM on January 2, 2014 [2 favorites]
To update them to today's conditions you'd need to supply 11, 12 and 13-hour recording strips and institute harsh punishments for users who failed to fit the correct strip on the correct day.
To do it with the same clockwork and just replacement strips you'd actually need twelve different versions of the 11-hour and 13-hour strips, or otherwise some method to indicate which hour is skipped or doubled, assuming that a watchman's shift can begin at any hour of the day. And of course daylight savings time is just one intricacy and merely the tip of the iceberg even for the issues mentioned in the video in the OP, which is itself basically an overview of a intro to the possible problems to be encountered.
posted by XMLicious at 10:04 AM on January 2, 2014
To be fair, those watchclocks were designed before the mind-boggling insanity that is Daylight Saving Time was even a drool on the chin of the sadistic lunatic who invented it. To update them to today's conditions you'd need to supply 11, 12 and 13-hour recording strips and institute harsh punishments for users who failed to fit the correct strip on the correct day.
Obviously none of you guys understand the basic concept of a watchclock. You just look at the strip and see if the marks occur at roughly the same time every day. You don't really even need to know the time each mark is recorded, as long as they line up. After a DST shift, all the marks will still line up during that period. In most scenarios, you don't really even need to record the actual time, DST or Standard. You just initialize the watchclock when the driver leaves the depot, and you record the duration of time between stops.
It seems that advanced technology has made people feebleminded and unable to conceptualize these simple concepts. The very fact that this invented scenario was:
I have a truck that runs night shift, 7 days a week, and every day at 1:30am I need to check where that truck is. If it's not at the right place, the driver gets a mark on their record.
is because the concept of recording check ins at locations by time and place is ingrained into business culture, because of the wide use of watchclocks for so many decades.
Yeah, yeah, I know your next move. He has a different location to be in at 1:30 AM every night of the week, or even different locations on a varying schedule. So you put different keys at each check in station. They each record a different mark.
I understand why this concept is so unfamiliar. It doesn't involve GPS satellites and radio communications and databases of time zones and DST. It isn't an abstract concept. It is fundamental idea. Let me tell you a story.
Long long ago, back in the 1880s, there was a company called the International Time Recording Company. They copied concepts from German watchclock makers, and used them to build Time Recorders, machines that would mechanically stamp times on cards so the recordings could not be tampered with by employees. Soon this company merged with the Tabulating Machine Company, founded by this guy named Herman Hollerith, who had this crazy idea of punching holes in paper to record data. Then they merged with another company, the National Cash Register company, which had the bright idea of using those little punched holes in receipts on their cash registers, to ensure that cashiers weren't skimming money.
When the companies merged, they named themselves International Business Machines, known today as IBM, and they created nearly all the fundamental technologies that you guys are talking about. Moreover, they invented the business procedures to use them, and worldwide industries adapted to those procedures. And this all happened because some businessmen wanted impartial machine records that their employees were in a specific time and place.
posted by charlie don't surf at 4:44 PM on January 2, 2014
Obviously none of you guys understand the basic concept of a watchclock. You just look at the strip and see if the marks occur at roughly the same time every day. You don't really even need to know the time each mark is recorded, as long as they line up. After a DST shift, all the marks will still line up during that period. In most scenarios, you don't really even need to record the actual time, DST or Standard. You just initialize the watchclock when the driver leaves the depot, and you record the duration of time between stops.
It seems that advanced technology has made people feebleminded and unable to conceptualize these simple concepts. The very fact that this invented scenario was:
I have a truck that runs night shift, 7 days a week, and every day at 1:30am I need to check where that truck is. If it's not at the right place, the driver gets a mark on their record.
is because the concept of recording check ins at locations by time and place is ingrained into business culture, because of the wide use of watchclocks for so many decades.
Yeah, yeah, I know your next move. He has a different location to be in at 1:30 AM every night of the week, or even different locations on a varying schedule. So you put different keys at each check in station. They each record a different mark.
I understand why this concept is so unfamiliar. It doesn't involve GPS satellites and radio communications and databases of time zones and DST. It isn't an abstract concept. It is fundamental idea. Let me tell you a story.
Long long ago, back in the 1880s, there was a company called the International Time Recording Company. They copied concepts from German watchclock makers, and used them to build Time Recorders, machines that would mechanically stamp times on cards so the recordings could not be tampered with by employees. Soon this company merged with the Tabulating Machine Company, founded by this guy named Herman Hollerith, who had this crazy idea of punching holes in paper to record data. Then they merged with another company, the National Cash Register company, which had the bright idea of using those little punched holes in receipts on their cash registers, to ensure that cashiers weren't skimming money.
When the companies merged, they named themselves International Business Machines, known today as IBM, and they created nearly all the fundamental technologies that you guys are talking about. Moreover, they invented the business procedures to use them, and worldwide industries adapted to those procedures. And this all happened because some businessmen wanted impartial machine records that their employees were in a specific time and place.
posted by charlie don't surf at 4:44 PM on January 2, 2014
You really really don't like to admit when you are wrong do you?
posted by aspo at 5:59 PM on January 2, 2014 [1 favorite]
posted by aspo at 5:59 PM on January 2, 2014 [1 favorite]
If you want to believe I am wrong, and thus choose to live in a world of needless complexity, feel free to do so. But I can show you the way out.
You really ought to read "The Hidden Dimension" by Ed Hall. You believe in monochronic time. That is your cultural bias and a very narrow view that most cultures do not share. So please do not insist that everyone should join your delusion.
posted by charlie don't surf at 7:31 PM on January 2, 2014
You really ought to read "The Hidden Dimension" by Ed Hall. You believe in monochronic time. That is your cultural bias and a very narrow view that most cultures do not share. So please do not insist that everyone should join your delusion.
posted by charlie don't surf at 7:31 PM on January 2, 2014
People assume that time is a strict progression of cause-to-effect....
posted by EmpressCallipygos at 7:34 PM on January 2, 2014
posted by EmpressCallipygos at 7:34 PM on January 2, 2014
In most scenarios, you don't really even need to record the actual time, DST or Standard.
Ah yes, "it'll work most of the time". And whenever a user needs the system to do something else—in the inconceivable eventuality that the enterprise might need to know something about the watchman's activities other than checking the duration between his stops immediately at the end of his shift, or that the composition of several of these "works most of the time" approaches produces an overall process that does not work most of the time—that need is a fault on the part of the user, rather than a flaw in the system or a failure of forethought on the part of the system's developer. It's just a feebleminded obsession with needless complexity.
You're very much like many programmers I've worked with, and had to clean up after: believe me, it is not some innate mindset of modernity or our culture to anticipate this stuff. And defensively proclaiming that whatever simple solution you cobbled together is the perfect one, for all sorts of reasons that have nothing to do with the real-world problem that actually needs to be solved... why put a full ass into it when half-assed will do? I suppose it keeps the rest of us in business, though. (Or in government, or in academia.) Keep on conceptualizing your simple concepts that the rest of us are too feebleminded for, dude.
posted by XMLicious at 10:40 PM on January 2, 2014 [1 favorite]
You believe in monochronic time. That is your cultural bias and a very narrow view that most cultures do not share. So please do not insist that everyone should join your delusion.
Oh FFS.
What the programmer believes or doesn't believe about time is entirely irrelevant in the context of the relationship between the programmer-for-hire and their client.
What matters is correctly capturing the client's business rules and implementing the required software functions in a way that works within that context.
Yes the fact that the vast bulk of business culture is enslaved by a clock as completely fucking insane as the ones we all have to code around is some kind of horrible delusional condition. That's the point. That's what we're all moaning about. We don't get to take some purist academic position of refusal to deal with time-related programming because we're all polychronic and culturally aware and stuff. Try that on a client and you won't have a client. As a working programmer you just have to hold your nose and deal with it.
And if you think it's simple, you will screw it up, and one of us will have to step into the shitpile you created and shovel it clean. And we will think less of you as a result, and mock your efforts on The Daily WTF, because people who simply can't be arsed to do their work properly deserve no professional respect.
posted by flabdablet at 11:08 PM on January 2, 2014 [5 favorites]
Oh FFS.
What the programmer believes or doesn't believe about time is entirely irrelevant in the context of the relationship between the programmer-for-hire and their client.
What matters is correctly capturing the client's business rules and implementing the required software functions in a way that works within that context.
Yes the fact that the vast bulk of business culture is enslaved by a clock as completely fucking insane as the ones we all have to code around is some kind of horrible delusional condition. That's the point. That's what we're all moaning about. We don't get to take some purist academic position of refusal to deal with time-related programming because we're all polychronic and culturally aware and stuff. Try that on a client and you won't have a client. As a working programmer you just have to hold your nose and deal with it.
And if you think it's simple, you will screw it up, and one of us will have to step into the shitpile you created and shovel it clean. And we will think less of you as a result, and mock your efforts on The Daily WTF, because people who simply can't be arsed to do their work properly deserve no professional respect.
posted by flabdablet at 11:08 PM on January 2, 2014 [5 favorites]
I want to see the steampunk version of this video with slide rulers and calipers, small extra gear clocks in bell jars, ticker tapes feeding into punch card punchers, and files and files of punch cards each with a unique use case, time adjustment, and trained monkeys climbing bookcases using pincer extending arms to reach the highest volumes--which are not folios, but scrolls--of the time keeper's almanac which they drop into vaccume chutes. All this in the background. And the presenter is telling you how fantastically accurate are the modern advances in time keeping. Wanker has all the power in the world in his laptop and it looks like he's sitting in an office--so he prolly has a job. What he go to be mad about? Really?
posted by xtian at 8:57 AM on January 3, 2014 [2 favorites]
posted by xtian at 8:57 AM on January 3, 2014 [2 favorites]
We use a finger-in-the-air point scoring system for tickets at work starting at 1 (trivial), on through 2, 4, 8 and up to 16 (too complicated to contemplate).
The rule for just about anything touching dates is 8. Dates is eights.
posted by bonaldi at 8:04 AM on January 7, 2014 [1 favorite]
The rule for just about anything touching dates is 8. Dates is eights.
posted by bonaldi at 8:04 AM on January 7, 2014 [1 favorite]
Suppose I'm writing a program that keeps track of appointments.
Aaaargh, I did exactly this at a previous gig, plus it had the added fun of appointments 24 hours a day, so you would have tasks scheduled for the moment a DST transition happened. I spent days trying to tell people that we were doing times wrong, and no just making everything UTC wouldn't fix it, and no just making everything UTC plus an offset wouldn't fix it.
posted by markr at 2:11 AM on January 8, 2014
Aaaargh, I did exactly this at a previous gig, plus it had the added fun of appointments 24 hours a day, so you would have tasks scheduled for the moment a DST transition happened. I spent days trying to tell people that we were doing times wrong, and no just making everything UTC wouldn't fix it, and no just making everything UTC plus an offset wouldn't fix it.
posted by markr at 2:11 AM on January 8, 2014
« Older "This is my team. This is C O P R A." | Jacco Gardner's Cabinet of Curiosities:... Newer »
This thread has been archived and is closed to new comments
Further reading, for those interested in learning more about such things.
posted by jeffamaphone at 3:05 PM on December 31, 2013 [2 favorites]