<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: In the zone</title>
	<atom:link href="http://bit-player.org/2010/in-the-zone/feed" rel="self" type="application/rss+xml" />
	<link>http://bit-player.org/2010/in-the-zone</link>
	<description>An amateur's outlook on computation and mathematics.</description>
	<pubDate>Thu, 17 May 2012 10:14:47 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Jim Ward</title>
		<link>http://bit-player.org/2010/in-the-zone#comment-3185</link>
		<dc:creator>Jim Ward</dc:creator>
		<pubDate>Thu, 26 Aug 2010 20:23:43 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=776#comment-3185</guid>
		<description>With GPS becoming ubiquitous, there's no reason we couldn't go to a longitude based time system. Your local time = GPS UTC + corrected to your nearest longitude.</description>
		<content:encoded><![CDATA[<p>With GPS becoming ubiquitous, there&#8217;s no reason we couldn&#8217;t go to a longitude based time system. Your local time = GPS UTC + corrected to your nearest longitude.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan</title>
		<link>http://bit-player.org/2010/in-the-zone#comment-3184</link>
		<dc:creator>Dan</dc:creator>
		<pubDate>Thu, 26 Aug 2010 11:03:48 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=776#comment-3184</guid>
		<description>Matías: the northern hemisphere isn't all in agreement -- here in Korea (and Japan too, I think), the academic year starts in March and ends in December, so it matches the calendar year. I suppose I was thinking "North America and Europe" when I wrote "western"...</description>
		<content:encoded><![CDATA[<p>Matías: the northern hemisphere isn&#8217;t all in agreement &#8212; here in Korea (and Japan too, I think), the academic year starts in March and ends in December, so it matches the calendar year. I suppose I was thinking &#8220;North America and Europe&#8221; when I wrote &#8220;western&#8221;&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matías Giovannini</title>
		<link>http://bit-player.org/2010/in-the-zone#comment-3183</link>
		<dc:creator>Matías Giovannini</dc:creator>
		<pubDate>Thu, 26 Aug 2010 02:25:26 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=776#comment-3183</guid>
		<description>@Dan, it's the northern hemisphere's school year that spans a year; here in the South things are more orderly for schoolchildren.

@John, of course the problem lies in conflating "tomorrow" with "24 hours from now": dates in the past but especially in the future should never be treated as intervals from the present. It's not that there are two midnights on the day savings time goes into effect, it's that there's less than 24 hours between civil middays straddling such a change.</description>
		<content:encoded><![CDATA[<p>@Dan, it&#8217;s the northern hemisphere&#8217;s school year that spans a year; here in the South things are more orderly for schoolchildren.</p>
<p>@John, of course the problem lies in conflating &#8220;tomorrow&#8221; with &#8220;24 hours from now&#8221;: dates in the past but especially in the future should never be treated as intervals from the present. It&#8217;s not that there are two midnights on the day savings time goes into effect, it&#8217;s that there&#8217;s less than 24 hours between civil middays straddling such a change.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan</title>
		<link>http://bit-player.org/2010/in-the-zone#comment-3180</link>
		<dc:creator>Dan</dc:creator>
		<pubDate>Wed, 25 Aug 2010 09:27:25 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=776#comment-3180</guid>
		<description>One big problem with everyone-use-UTC is that you would get day changes in the middle of a typical workday. I live in South Korea, which is UTC+9. If we simply used UTC for time here, what is now a 8:00 to 17:00 workday would become 23:00 to 8:00 and would cross a (calendar) day boundary. What if you leave a deposit at your bank right before going to work, but they don't process it until lunchtime -- on what day would/should the deposit be credited? Would banks need to recalibrate their systems to account for the local time?

Of course, there are other time and calendar things that cross boundaries -- the western school year starts in one calendar year and ends in the next, and there are people that work 11-7 graveyard shifts -- but my guess is that having a calendar day match a solar day is too useful to give up. 

(BTW, John Cowan's example of Kashi has a counterpart: Japan's northern island of Hokkaido is in the same time zone as the rest of Japan and Korea, but is far enough east so that during the summer the sun sets quite early, even though Hokkaido is pretty far north and has quite long days during the summer.  Personally, I think both Japan and Korea should permanently jump ahead an hour, but like Brian, no one's going to do that on my say-so. :)</description>
		<content:encoded><![CDATA[<p>One big problem with everyone-use-UTC is that you would get day changes in the middle of a typical workday. I live in South Korea, which is UTC+9. If we simply used UTC for time here, what is now a 8:00 to 17:00 workday would become 23:00 to 8:00 and would cross a (calendar) day boundary. What if you leave a deposit at your bank right before going to work, but they don&#8217;t process it until lunchtime &#8212; on what day would/should the deposit be credited? Would banks need to recalibrate their systems to account for the local time?</p>
<p>Of course, there are other time and calendar things that cross boundaries &#8212; the western school year starts in one calendar year and ends in the next, and there are people that work 11-7 graveyard shifts &#8212; but my guess is that having a calendar day match a solar day is too useful to give up. </p>
<p>(BTW, John Cowan&#8217;s example of Kashi has a counterpart: Japan&#8217;s northern island of Hokkaido is in the same time zone as the rest of Japan and Korea, but is far enough east so that during the summer the sun sets quite early, even though Hokkaido is pretty far north and has quite long days during the summer.  Personally, I think both Japan and Korea should permanently jump ahead an hour, but like Brian, no one&#8217;s going to do that on my say-so. :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: brian</title>
		<link>http://bit-player.org/2010/in-the-zone#comment-3177</link>
		<dc:creator>brian</dc:creator>
		<pubDate>Tue, 24 Aug 2010 18:57:00 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=776#comment-3177</guid>
		<description>@John Cowan: I meant a world with &lt;em&gt;no&lt;/em&gt; time zones, not a world with &lt;em&gt;one&lt;/em&gt; time zone. Instead of adjusting the clock to the local cycle of day and night, we wake in daylight and sleep in the dark regardless of what the clock says. If the work day is 9 to 5 on the east coast of the U.S., it could be 6 to 2 out west.

But I should emphasize again that I haven't really thought through the consequences of this change. It eliminates some sources of confusion but would doubtless break other things. To me the big plus is that we can think of time as a monotonically increasing sequence of moments, essentially the value of a counter. The big minus is that the entire human population has to alter habits that have become pretty deeply ingrained in the few centuries since mechanical timekeeping was introduced.

In any case, not to worry: No one is about to adopt such a plan on &lt;em&gt;my&lt;/em&gt; say-so.</description>
		<content:encoded><![CDATA[<p>@John Cowan: I meant a world with <em>no</em> time zones, not a world with <em>one</em> time zone. Instead of adjusting the clock to the local cycle of day and night, we wake in daylight and sleep in the dark regardless of what the clock says. If the work day is 9 to 5 on the east coast of the U.S., it could be 6 to 2 out west.</p>
<p>But I should emphasize again that I haven&#8217;t really thought through the consequences of this change. It eliminates some sources of confusion but would doubtless break other things. To me the big plus is that we can think of time as a monotonically increasing sequence of moments, essentially the value of a counter. The big minus is that the entire human population has to alter habits that have become pretty deeply ingrained in the few centuries since mechanical timekeeping was introduced.</p>
<p>In any case, not to worry: No one is about to adopt such a plan on <em>my</em> say-so.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Cowan</title>
		<link>http://bit-player.org/2010/in-the-zone#comment-3175</link>
		<dc:creator>John Cowan</dc:creator>
		<pubDate>Tue, 24 Aug 2010 16:36:23 +0000</pubDate>
		<guid isPermaLink="false">http://bit-player.org/?p=776#comment-3175</guid>
		<description>&lt;i&gt;I begin to wonder if the whole railroad-age concept of time zones hasn’t outlived its usefulness.&lt;/i&gt;

Only if you think the concept of working in the daytime and sleeping at night has lost its usefulness.  Our bodily cycles are still synchronized by the Sun, despite working in windowless offices and staying up late with electric lights; even in a large city like New York, only about 6% of the population works the graveyard shift.

At present the worst case is the city of Kashi (Kashgar) in extreme western China, which is on Beijing time (UTC+8) even though its solar time is more like UTC+5; it's at about the same longitude as New Delhi.  Office workers there begin work at about sunrise and go home in mid-afternoon, solarly speaking.

The only fully general solution to the calendar problem is to allow &lt;i&gt;all&lt;/i&gt; future dates to be specified in the local civil time (LCT) of a particular location.  Financial instruments such as bonds, options, and futures, for example, are usually specified with respect to a certain date at 5 PM New York or London LCT.  This cannot be directly converted to an unvarying standard such as UTC, because Congress or Parliament might alter either the DST hours or even the underlying standard time zone as a whole at that location before the event occurs.</description>
		<content:encoded><![CDATA[<p><i>I begin to wonder if the whole railroad-age concept of time zones hasn’t outlived its usefulness.</i></p>
<p>Only if you think the concept of working in the daytime and sleeping at night has lost its usefulness.  Our bodily cycles are still synchronized by the Sun, despite working in windowless offices and staying up late with electric lights; even in a large city like New York, only about 6% of the population works the graveyard shift.</p>
<p>At present the worst case is the city of Kashi (Kashgar) in extreme western China, which is on Beijing time (UTC+8) even though its solar time is more like UTC+5; it&#8217;s at about the same longitude as New Delhi.  Office workers there begin work at about sunrise and go home in mid-afternoon, solarly speaking.</p>
<p>The only fully general solution to the calendar problem is to allow <i>all</i> future dates to be specified in the local civil time (LCT) of a particular location.  Financial instruments such as bonds, options, and futures, for example, are usually specified with respect to a certain date at 5 PM New York or London LCT.  This cannot be directly converted to an unvarying standard such as UTC, because Congress or Parliament might alter either the DST hours or even the underlying standard time zone as a whole at that location before the event occurs.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

