Thanks for putting this together Chris. I am in favor of option (1) Pure UTC. I think it is the simplest to implement, and to get from / to other time zones is one ufunc application.
On the other hand, option (3) full time zone support isn't too bad either. It is more work to implement but a lot of code could be borrowed from pytz -- which makes timezones usable in python at all. Option (2), what datetime does, is the wrong model. This is more complicated in both the implementation and API, and leads to lots of broken code, weird errors, and no clear right way of doing thing. Be Well Anthony On Fri, Apr 12, 2013 at 2:57 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > On Fri, Apr 12, 2013 at 9:52 AM, Riccardo De Maria > <riccardodema...@gmail.com> wrote: > > Not related to leap seconds and physically accurate time deltas, I have > just > > noticed that SQLite has a nice API: > > > > http://www.sqlite.org/lang_datefunc.html > > > > that one can be inspired from. The source contains a date.c which looks > > reasonably clear. > > well, I don't see any timezone support in there at all. It appears the > use UTC, though I"m not entierly sure from the docs what now() would > return. > > So I think it's pretty much like my "use UTC" proposal. > > > -Chris > > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion