<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 19, 2015 at 3:34 PM, Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span> wrote:<br><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"><div><span style="font-size:12.8px"><br></span></div><div><span class=""><blockquote style="font-size:12.8px">> In Python 3.6, datetime.now() will return different values in the first and the second repeated hour in the "fall-back fold." > If you allow datetime.datetime to numpy.datetime64 conversion, you should decide what you do with that difference. <br></blockquote></span><span style="font-size:12.8px">Indeed. Though will that only occur with timezones that have DST? I know I'd be fine with NOT being able to create a numpy datetime64 from a non-naive datetime object.</span></div></blockquote></div><br><span style="font-size:12.8px">datetime.now() returns *naive* </span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">datetime objects unless you supply the timezone.  In Python 3.6 *naive* datetime objects will have the fold attribute and </span><span style="font-size:12.8px">datetime.now()</span><span style="font-size:12.8px">  will occasionally return fold=1 values unless your system timezone has a fixed UTC offset.</span><br></div></div>