Time Zones and datetime64
Recent discussion has made it clear that the timezone handling in the current (numpy1.7) version of datetime64 is broken. Below is a discussion of some possible solutions, hopefully including most of the comments made on the recent thread on this list. http://mail.scipy.org/pipermail/numpy-discussion/2013-April/066038.html The intent it that with a bit more discussion (focused, in this thread at least) on the time zone issues, rather than other DateTIme64 issues, we can start a new datetime64 NEP. Background: =============================== The current version (numpy 1.7) of datetime64 appears to handle timezones in the following ways: datetime64s are assumed to be in UTC internally. Time zone translation is done on I/O -- i.e creating a new datetime64 and outputting to text format or as a datetime.datetime object. When creating a datetime64 from an ISO string, the timezone info in the string is respected. If there is no timezone info in the string, the system time zone (locale setting) is used. On output (i.e.converting to text: __str__ and __repr__) the system locale is used to set the timezone. In [9]: np.datetime64('2013-04-08T12:00:00Z') Out[9]: numpy.datetime64('2013-04-08T05:00:00-0700') In [10]: np.datetime64('2013-04-08T12:00:00') Out[10]: numpy.datetime64('2013-04-08T12:00:00-0700') However, if a datetime,datetime is used without a tzinfo object (the common case, as no tzinfo objects are provided with the python stdlib), the timezone is assumed to be UTC: In [13]: dt Out[13]: datetime.datetime(2013, 4, 8, 12, 0) In [14]: np.datetime64(dt) Out[14]: numpy.datetime64('2013-04-08T05:00:00.000000-0700') which can give some odd results, as it's different if you convert the datetime object to a iso string first: In [15]: np.datetime64(dt.isoformat()) Out[15]: numpy.datetime64('2013-04-08T12:00:00-0700') Converting from a datetime64 to a datetime object uses the UTC time (the internal representation with no offset). Issues with the current configuration: =============================== Using the locale time zone is a long standing tradition, and used by the C standard library time functions. However, it is almost always NOT what one wants in a typical numpy application. When working with Scientific (and financial) datasets, the time zone of the data at hand is likely to have nothing to do with the timezone of the computer the code is running on. Also, with cloud computing and web applications, the time zone of the machine on which the code is running is irrelevant to the user. A number of early-adopters of datetime64 have found that they have needed to wrap creating and use of datetime64 arrays to override the timezone behavior. The current implementation may be natural for some interactive use, but that's often not the case, and is particularly problematic when datetime.datetime.now() gives locale lime, but with no time zone info, so numpy actually appears to shift it. In [19]: datetime.datetime.now().isoformat() Out[19]: '2013-04-08T12:05:26.157475' In [20]: np.datetime64(datetime.datetime.now()) Out[20]: numpy.datetime64('2013-04-08T05:05:45.813027-0700') This is really ugly -- and regardless if we like what the std lib does, we need to deal with it. The python standard library datetime implementation uses "naive" datetimes by default, with the provision for an optional "tzinfo" object, so that the user can supply timezone info if desired, However, the library does not provide any tzinfo objects out of the box. This is because timezones are messy, complicated, and change over time, and the core python devs did not want to be in the position of maintaining that code. There is a third party "pytz" package (http://pytz.sourceforge.net/) that provides a pretty complete implementation of time zone handling for those that need it. Note also that in the current implementation, The busday functions just operate on datetime64[D]. There is no timezone interaction there -- which makes it very hard for them to be useful, as it's a bit tricky to make sure your datetime64 arrays are in the correct time zone for your application. In fact, they are assuming that datetime64 is time zone naive, even though the I/O functions assume locale time. Proposed Alternatives: ====================== Principles: ------------------ * Partial time zone handling is probably worse than none. * The library should never apply the locale timezone (or any other) unless explicitly requested by the user. * It should be possible (and easy) to use "naive" datetime64 arrays. 1) A naive datetime64: ==================== This would follow, more or less, the python stdlib datetime approach (with no tzinfo object) -- ignore timezones entirely. This model leaves all time zone handling up to the user. In general, when working with this method, applications either: use UTC everywhere, or use "local time" everywhere, where local time is simply "all data is in the same time zone" and it's up to the user (or lib code) to make sure that's correct. Issues: ------------------ The main issue with a naive datetime64 is what to do on creation if time zone information is supplied (i.e in a ISO 8601 string, or datetime object with non-None tzinfo). Options include: - ignore the TZ info - raise an exception if there is a TZ adjustment (other than UTC, 00:00, or Z) I propose that we raise an exception, unless there is a way to pass an optional flag in to request timezone conversion. note that the stdlib datetime package does not provide an ISO8601 parsing function, so it has ignored the issue. There is also the issue of what to provide on output/conversion. I propose: - a datetime object with no tzinof - ISO8601 with no tz adjustment np.datetime_as_string() could be used with options to allow the user to request a time zone offset. 1) UTC-only ==================== This would be very similar to a naive datetime64 -- there are no timezone adjustments with pure UTC -- and would be similar to the current implementation, except for I/O: On conversion to datetime64, time zone offset would be respected, if it exists in the ISO8601 string or the datetime object has a tzinfo attribute. The value would be stored in UTC. If there is no timezone info in the input string or datetime objects, UTC is assumed. On output -- UTC is used, no offset computed. Issues: ------------------ The ISO string produced on output would logically contain the "Z" flag to indicate UTC. This may confuse some apps that really expect a naive datetime. If there were a way to pass in a flag to create ISO strings indicating the time zone, that would be perfect, probably using np.datetime_as_string() 3) Optional time zone support ========================== This would follow the standard library approach -- provide a hook for a tzinfo object -- and if there, handle properly. This would allow one to mix and match datetime64s that are in different time zones, etc. issues: ---------------- The biggest issue is that to be useful, you'd need a comprehensive tzinfo package. pytz provides one, but then you'd need to go through the python layer for every item in an array -- killing performance. However, perhaps that would be worth it for those that need it, and folks that need performance could use naive datetime64s. There apparently is also a datetime library in boost that has a nice timezone object which could be used as inspiration for an equivalent in NumPy. That could be a lot of work, though. 3) Full time zone support ========================== This would be similar to the above, except that every datetime64 array would be required to carry time zone info. This would probably be reasonable, as one could use UTC everywhere if you wanted the simple case. But it would require that a comprehensive tzinfo package be included with numpy -- likely something we don't want to have to maintain (even if someone wants to built it in the first place) issues: ----------- We would still want ways to input/output naive datetimes -- some app simply don't want to deal with all this! As I (Chris Barker) am not in a postion to implement anything, I advocate the simplest possible approach -- which I think is Naive datetime and/or UTC only. But if people want more, and someone wants to implement it, great! Please add your comment, and maybe we'll get a NEP together. -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.Barker@noaa.gov
On Mon, Apr 8, 2013 at 12:24 PM, Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:
Recent discussion has made it clear that the timezone handling in the current (numpy1.7) version of datetime64 is broken. Below is a discussion of some possible solutions, hopefully including most of the comments made on the recent thread on this list.
http://mail.scipy.org/pipermail/numpy-discussion/2013-April/066038.html
The intent it that with a bit more discussion (focused, in this thread at least) on the time zone issues, rather than other DateTIme64 issues, we can start a new datetime64 NEP.
This looks great, thanks for putting it together! I've put some comments inline.
Background: ===============================
The current version (numpy 1.7) of datetime64 appears to handle timezones in the following ways:
datetime64s are assumed to be in UTC internally. Time zone translation is done on I/O -- i.e creating a new datetime64 and outputting to text format or as a datetime.datetime object.
It might be better to say "defined" instead of "assumed", because that was an explicit choice.
When creating a datetime64 from an ISO string, the timezone info in the string is respected. If there is no timezone info in the string, the system time zone (locale setting) is used. On output (i.e.converting to text: __str__ and __repr__) the system locale is used to set the timezone.
In [9]: np.datetime64('2013-04-08T12:00:00Z') Out[9]: numpy.datetime64('2013-04-08T05:00:00-0700')
In [10]: np.datetime64('2013-04-08T12:00:00') Out[10]: numpy.datetime64('2013-04-08T12:00:00-0700')
However, if a datetime,datetime is used without a tzinfo object (the common case, as no tzinfo objects are provided with the python stdlib), the timezone is assumed to be UTC:
In [13]: dt Out[13]: datetime.datetime(2013, 4, 8, 12, 0)
In [14]: np.datetime64(dt) Out[14]: numpy.datetime64('2013-04-08T05:00:00.000000-0700')
which can give some odd results, as it's different if you convert the datetime object to a iso string first:
In [15]: np.datetime64(dt.isoformat()) Out[15]: numpy.datetime64('2013-04-08T12:00:00-0700')
Converting from a datetime64 to a datetime object uses the UTC time (the internal representation with no offset).
Issues with the current configuration: ===============================
Using the locale time zone is a long standing tradition, and used by the C standard library time functions. However, it is almost always NOT what one wants in a typical numpy application. When working with Scientific (and financial) datasets, the time zone of the data at hand is likely to have nothing to do with the timezone of the computer the code is running on. Also, with cloud computing and web applications, the time zone of the machine on which the code is running is irrelevant to the user. A number of early-adopters of datetime64 have found that they have needed to wrap creating and use of datetime64 arrays to override the timezone behavior.
The current implementation may be natural for some interactive use, but that's often not the case, and is particularly problematic when datetime.datetime.now() gives locale lime, but with no time zone info, so numpy actually appears to shift it.
In [19]: datetime.datetime.now().isoformat() Out[19]: '2013-04-08T12:05:26.157475'
In [20]: np.datetime64(datetime.datetime.now()) Out[20]: numpy.datetime64('2013-04-08T05:05:45.813027-0700')
This is really ugly -- and regardless if we like what the std lib does, we need to deal with it.
The python standard library datetime implementation uses "naive" datetimes by default, with the provision for an optional "tzinfo" object, so that the user can supply timezone info if desired, However, the library does not provide any tzinfo objects out of the box. This is because timezones are messy, complicated, and change over time, and the core python devs did not want to be in the position of maintaining that code. There is a third party "pytz" package (http://pytz.sourceforge.net/) that provides a pretty complete implementation of time zone handling for those that need it.
Note also that in the current implementation, The busday functions just operate on datetime64[D]. There is no timezone interaction there -- which makes it very hard for them to be useful, as it's a bit tricky to make sure your datetime64 arrays are in the correct time zone for your application. In fact, they are assuming that datetime64 is time zone naive, even though the I/O functions assume locale time.
The datetime64[D] type itself doesn't interact with time zones, for example: In [2]: np.datetime64('2000-03-12') Out[2]: numpy.datetime64('2000-03-12') doesn't use a time zone. Where time zones come into play is when converting between datetime64[D] and datetime64[s], or other time-unit datetimes: In [12]: a = np.array(["2012-03-02T22:00", "2013-02-01T01:00"], dtype='M8') In [13]: a Out[13]: array(['2012-03-02T22:00-0800', '2013-02-01T01:00-0800'], dtype='datetime64[m]') In [14]: a.astype('M8[D]') Out[14]: array(['2012-03-03', '2013-02-01'], dtype='datetime64[D]') The casting rules disallow conversion from time to date units, except under the 'unsafe' rule. That's unfortunately the default for the astype function though, so if we override the rule, we get: In [15]: a.astype('M8[D]', casting='same_kind') --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-15-93cfc21b90d8> in <module>() ----> 1 a.astype('M8[D]', casting='same_kind') TypeError: Cannot cast array from dtype('<M8[m]') to dtype('<M8[D]') according to the rule 'same_kind' Because there's no equivalent to datetime_as_string for converting to dates, to handle the time zone requires this kind of trickery: In [17]: np.array([x[:10] for x in np.datetime_as_string(a, timezone='local')], dtype='M8[D]') Out[17]: array(['2012-03-02', '2013-02-01'], dtype='datetime64[D]') Proposed Alternatives:
======================
Principles: ------------------
* Partial time zone handling is probably worse than none. * The library should never apply the locale timezone (or any other) unless explicitly requested by the user. * It should be possible (and easy) to use "naive" datetime64 arrays.
1) A naive datetime64: ====================
This would follow, more or less, the python stdlib datetime approach (with no tzinfo object) -- ignore timezones entirely. This model leaves all time zone handling up to the user. In general, when working with this method, applications either: use UTC everywhere, or use "local time" everywhere, where local time is simply "all data is in the same time zone" and it's up to the user (or lib code) to make sure that's correct.
Issues: ------------------
The main issue with a naive datetime64 is what to do on creation if time zone information is supplied (i.e in a ISO 8601 string, or datetime object with non-None tzinfo). Options include: - ignore the TZ info - raise an exception if there is a TZ adjustment (other than UTC, 00:00, or Z)
I'd still raise the exception for 00:00 and Z, to me they're more like the other time zone specifications than no time zone.
I propose that we raise an exception, unless there is a way to pass an optional flag in to request timezone conversion.
note that the stdlib datetime package does not provide an ISO8601 parsing function, so it has ignored the issue.
There is also the issue of what to provide on output/conversion. I propose: - a datetime object with no tzinof - ISO8601 with no tz adjustment
np.datetime_as_string() could be used with options to allow the user to request a time zone offset.
Another thing to consider is adding some global state for default printing of datetimes, similar to that for controlling the number of decimals when printing floats. I don't like this kind of global state, but it would match NumPy's current practice.
1) UTC-only ====================
This would be very similar to a naive datetime64 -- there are no timezone adjustments with pure UTC -- and would be similar to the current implementation, except for I/O:
On conversion to datetime64, time zone offset would be respected, if it exists in the ISO8601 string or the datetime object has a tzinfo attribute. The value would be stored in UTC.
If there is no timezone info in the input string or datetime objects, UTC is assumed.
On output -- UTC is used, no offset computed.
Issues: ------------------
The ISO string produced on output would logically contain the "Z" flag to indicate UTC. This may confuse some apps that really expect a naive datetime.
If there were a way to pass in a flag to create ISO strings indicating the time zone, that would be perfect, probably using np.datetime_as_string()
3) Optional time zone support ==========================
This would follow the standard library approach -- provide a hook for a tzinfo object -- and if there, handle properly. This would allow one to mix and match datetime64s that are in different time zones, etc.
issues: ----------------
The biggest issue is that to be useful, you'd need a comprehensive tzinfo package. pytz provides one, but then you'd need to go through the python layer for every item in an array -- killing performance. However, perhaps that would be worth it for those that need it, and folks that need performance could use naive datetime64s.
There apparently is also a datetime library in boost that has a nice timezone object which could be used as inspiration for an equivalent in NumPy. That could be a lot of work, though.
3) Full time zone support ==========================
This would be similar to the above, except that every datetime64 array would be required to carry time zone info. This would probably be reasonable, as one could use UTC everywhere if you wanted the simple case. But it would require that a comprehensive tzinfo package be included with numpy -- likely something we don't want to have to maintain (even if someone wants to built it in the first place)
issues: -----------
We would still want ways to input/output naive datetimes -- some app simply don't want to deal with all this!
As I (Chris Barker) am not in a postion to implement anything, I advocate the simplest possible approach -- which I think is Naive datetime and/or UTC only. But if people want more, and someone wants to implement it, great!
Please add your comment, and maybe we'll get a NEP together.
Thanks again for putting this together, Mark
-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.Barker@noaa.gov _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Apr 10, 2013 at 4:21 AM, Colin J. Williams <cjwilliams43@gmail.com> wrote:
On Mon, Apr 8, 2013 at 12:24 PM, Chris Barker - NOAA Federal
Recent discussion has made it clear that the timezone handling in the current (numpy1.7) version of datetime64 is broken. Below is a discussion of some possible solutions, hopefully including most of the comments made on the recent thread on this list.
Is MxDateTime helpful?
Colin W,
How so? I remember MXDateTime from way back when before pyton had a datetime in the stdlib. I"m trying to remember why pyton itself didn't adopt MxDateTime rather make a new one, but I think: - The licensing may not have been appropriate - MxDateTIme is more ambitious -- the core python devs didn't want to support the whole thing These apply to numpy as well. The goal of python's DateTime is that it be the basis for more comprehensive DateTime packages, so having numpy work well with it makes sense. Anyway, if MxDateTime has good timezone handling, it might be nice if numpy could allow users to optionally plug that in -- also having an easy MxDateitme => datetiem64 conversion could be nice. But we wouldn't want it as a dependency. If someone wants to take a good look at it and see what lessons we can learn, that would be great. (note: I have no idea how compatible MxDateTime and datetime.datetime are.. that would be nice to know.) -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.Barker@noaa.gov
Thanks for the effort. I think one should assume UTC when the time zones are not explicit. The library should handle correctly leap seconds, otherwise using unix time as a floating point number is already sufficient for many applications. Did you have a look to http://cr.yp.to/libtai.html? Riccardo
On 10/04/2013 18:55, Riccardo De Maria wrote:
The library should handle correctly leap seconds, otherwise using unix time as a floating point number is already sufficient for many applications.
Please define what you mean by "handle correctly leap seconds". As leap seconds are not predictable there is no way to correctly convert from a date and time representation representing a point in time in the future to a representation of number of seconds since an epoch on a TAI timebase. Either we forbid the (number of seconds since TAI epoch) to and from (date and time representation) for times in the future or I don't know ho to leap seconds may be correctly handled.
Did you have a look to http://cr.yp.to/libtai.html?
This library looks outdated. It does not list the leap second insertion occurred in 2012. Cheers, Daniele
Daniele Nicolodi <daniele <at> grinta.net> writes:
On 10/04/2013 18:55, Riccardo De Maria wrote:
The library should handle correctly leap seconds, otherwise using unix time as a floating point number is already sufficient for many applications.
Please define what you mean by "handle correctly leap seconds".
I know they are not predictable but one can always update a file or the binary itself for the ones introduced over the years. I mentioned leap seconds because it is only feature that I see that has deep implication in the implementaion and that may be useful to people that needs to compute precise time delta between time stamped events or need to parse dates like 2012-06-30T23:59:60UTC. At the moment I use unix time since leap seconds would be a corner case for me that I can handle manually. Unix time can be converted from and to date string using datetime and pytz and this is needed only during io operations, can be used as coordinates in matplotlib plots without or with a trivial customized ticker, time deltas are just differences (although not always physically accurate), can be used as a timestamp (with glitches during the leap second). But please take this comment as suggestions, I only wanted to share my use case. Riccardo
Hi Colin, Please ask Canopy question on the corresponding Enthought list, or Anaconda questions on the corresponding channel at continuum. This Mailing List is for discussion about NumPy itself, David On Thu, Apr 11, 2013 at 1:43 AM, Colin J. Williams <cjwilliams43@gmail.com>wrote:
Are CANOPY and Anaconda intended to work together?
I hope that this is envisaged.
Colin W.
Email not displaying correctly? View it in your browser.<http://us1.campaign-archive1.com/?u=e91b4574d5d1709a9dc4f7ab7&id=1a00a92634&e=1c81bde484>
*Greetings from Enthought,*
We are proud to announce our brand new product, *Enthought Canopy*<http://enthought.us1.list-manage.com/track/click?u=e91b4574d5d1709a9dc4f7ab7&id=4b85eb966d&e=1c81bde484>: a Python based analysis desktop and Python distribution for scientific and analytic computing that will help you solve your most complex problems.
*Enthought Canopy *is the follow on to the popular Enthought Python Distribution (EPD). But EPD users, have no fear. * Canopy* adds an advanced text editor, integrated IPython console, graphical package manager and online documentation to its EPD foundation. The *Canopy* analysis environment streamlines data analysis, visualization, algorithm design and application development for all its users.
We can't wait for you to try it out<http://enthought.us1.list-manage.com/track/click?u=e91b4574d5d1709a9dc4f7ab7&id=ad30a8221e&e=1c81bde484> .
The Enthought Team
You are receiving this email because you have subscribed to the Enthought Python Distribution, downloaded an EPD trial, or registered for one of our webinars.
Unsubscribe<http://enthought.us1.list-manage2.com/unsubscribe?u=e91b4574d5d1709a9dc4f7ab7&id=f3e67cce51&e=1c81bde484&c=1a00a92634> cjwilliams43@gmail.com from this list | Forward to a friend<http://us1.forward-to-friend1.com/forward?u=e91b4574d5d1709a9dc4f7ab7&id=1a00a92634&e=1c81bde484>| Update your profile<http://enthought.us1.list-manage.com/profile?u=e91b4574d5d1709a9dc4f7ab7&id=f3e67cce51&e=1c81bde484> *Our mailing address is:* Enthought, Inc. 515 Congress Ave. Austin, TX 78701
Add us to your address book<http://enthought.us1.list-manage2.com/vcard?u=e91b4574d5d1709a9dc4f7ab7&id=f3e67cce51>
*Copyright (C) 2013 Enthought, Inc. All rights reserved.*
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, On Wed, Apr 10, 2013 at 4:54 PM, David Cournapeau <cournape@gmail.com> wrote:
Hi Colin,
Please ask Canopy question on the corresponding Enthought list, or Anaconda questions on the corresponding channel at continuum.
This Mailing List is for discussion about NumPy itself,
David
On Thu, Apr 11, 2013 at 1:43 AM, Colin J. Williams <cjwilliams43@gmail.com> wrote:
Are CANOPY and Anaconda intended to work together?
I hope that this is envisaged.
Colin W.
Although it is also worth saying that I would have thought it is reasonable to ask about general numpy-related infrastructure here. Cheers, Matthew
On Fri, Apr 12, 2013 at 5:37 AM, Matthew Brett <matthew.brett@gmail.com> wrote:
Hi,
On Wed, Apr 10, 2013 at 4:54 PM, David Cournapeau <cournape@gmail.com> wrote:
Hi Colin,
Please ask Canopy question on the corresponding Enthought list, or Anaconda questions on the corresponding channel at continuum.
This Mailing List is for discussion about NumPy itself,
David
On Thu, Apr 11, 2013 at 1:43 AM, Colin J. Williams <cjwilliams43@gmail.com> wrote:
Are CANOPY and Anaconda intended to work together?
I hope that this is envisaged.
Colin W.
Although it is also worth saying that I would have thought it is reasonable to ask about general numpy-related infrastructure here.
Their respective support lines are the best places to get answers about those products, especially questions about their development roadmaps. Whether or not it is "reasonable" or on-topic to ask here, one won't get good answers here. -- Robert Kern
On Wed, Apr 10, 2013 at 9:55 AM, Riccardo De Maria <riccardodemaria@gmail.com> wrote:
The library should handle correctly leap seconds, otherwise using unix time as a floating point number is already sufficient for many applications.
well, we could have used floating point in datetime64, but integers have their advantages. But anyway, I'd like to keep the leap-second question separate from the time zone question -- they are orthogonal issues. So if you feel strongly about this, please write up a proposal, and start a new thread for that. leap-seconds don't happen to be my itch... Thanks, -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.Barker@noaa.gov
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. Riccardo
On Fri, Apr 12, 2013 at 9:52 AM, Riccardo De Maria <riccardodemaria@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.Barker@noaa.gov
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.barker@noaa.gov> wrote:
On Fri, Apr 12, 2013 at 9:52 AM, Riccardo De Maria <riccardodemaria@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.Barker@noaa.gov _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Apr 12, 2013 at 1:36 PM, Anthony Scopatz <scopatz@gmail.com> wrote:
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.
could you elaborate a bit more? I've never tried to use timezone support with datetime, so I have no idea what goes wrong -- but it looks reasonable to me. though it really punts on the hard stuff, so maybe no point. -Chris
Be Well Anthony
On Fri, Apr 12, 2013 at 2:57 PM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:
On Fri, Apr 12, 2013 at 9:52 AM, Riccardo De Maria <riccardodemaria@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.Barker@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
-- 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.Barker@noaa.gov
Colin J. Williams <cjwilliams43 <at> gmail.com> writes:
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.
I think so. There is no support for leap second either.
It's not clear whether the Julian day is an integer or contains a fractional part. Colin W.
In SQLite the internal representation is Julian day * 86400 * 1000. In astronomy the modified julian day is apparenly often used: CCIR RECOMMENDATION 457-1, USE OF THE MODIFIED JULIAN DATE BY THE STANDARD FREQUENCY AND TIME-SIGNAL SERVICES. There is python library with classes that support several time coordinate systems (TAI, UTC, ISO, JD, MJD, UNX, RDT, CDF, DOY, eDOY) http://spacepy.lanl.gov/doc/autosummary/spacepy.time.Ticktock.html I also found those page useful for a quick recap. http://tycho.usno.navy.mil/mjd.html http://tycho.usno.navy.mil/systime.html
participants (9)
-
Anthony Scopatz -
Chris Barker - NOAA Federal -
Colin J. Williams -
Daniele Nicolodi -
David Cournapeau -
Mark Wiebe -
Matthew Brett -
Riccardo De Maria -
Robert Kern