<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 29, 2015 at 10:42 AM, Łukasz Rekucki <span dir="ltr"><<a href="mailto:lrekucki@gmail.com" target="_blank">lrekucki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29 July 2015 at 19:37, Alexander Belopolsky<br>
<div><div class="h5"><<a href="mailto:alexander.belopolsky@gmail.com">alexander.belopolsky@gmail.com</a>> wrote:<br>> For example, "Find a day with the largest trading volume on the New<br>
> York Stock Exchange in 2014."<br><br>
> The exchange publishes its data in New York local time and you know<br>
> that trading hours are from 09:30 to 16:00 with a few exceptions that<br>
> are again published in the local time. </div></div></blockquote><div><br></div><div><snip></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"> The database is huge, so you<br>
> select the data by day, split it into chunks by 5 minutes, add up the<br>
> volumes for each day<br>
> and find maximum. Easy. No need to know when the DST transitions<br>
> were in New York in 2014. Got the same database from Paris? No need<br>
> to change your code.</div></div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">That's because your program does not need to be time zone aware *at<br>all* (it works on Local Datetime). Everyone already agrees that this<br>work.</blockquote><div><br></div><div>exactly -- this is where and why naive datetimes are, in fact very, very useful. </div><div>And see Skip's message -- I guess I haven't drunk the cool aid, but I agree that going full-on timezone aware would make this kind of thing harder.</div><div><br></div><div>For me, I think of naive datetimes as meaning "I know all the data i"m working with right now is in the same timezone (and I don't care about DST)"</div><div><br></div><div>So no -- this is not an example of wanting to do time arithmetic in the messy, DST aware, non-contiguous realm...</div><div><br></div><div>But I don't think anyone is proposing removing naive datetimes anyway.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"> Now try to do the same in UTC. I think my<br>
> program will finish before you stop arguing what "a day" is.<br></div></div></blockquote><div><br></div><div>actually -- it would hardly make it any harder, if we had "proper" time zone support:</div><div><br></div><div>You'd load your data into datetime objects, letting it know that it's in the US Eastern Time zone. then do all the same things -- datetime would deal with it for you.</div><div><br></div><div>For Paris, you *would* have to tell your script what timezone it's in.</div><div><br></div><div>But again, if that isn't in the dataset, then naive is what you want.</div><div><br></div><div>-Chris</div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>