Thanks to visit codestin.com
Credit goes to github.com

Skip to content

datetime64("now") is undocumented #10003

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
damiendr opened this issue Nov 11, 2017 · 5 comments
Open

datetime64("now") is undocumented #10003

damiendr opened this issue Nov 11, 2017 · 5 comments

Comments

@damiendr
Copy link

I found out that you can get the current UTC date with np.datetime64("now").

However this isn't documented here and there are a few things about the behaviour that aren't obvious. For instance it seems that the precision cannot be greater than one second:

In [95]: np.datetime64("now", "ms")
Out[95]: numpy.datetime64('2017-11-11T08:10:31.000')
@shoyer
Copy link
Member

shoyer commented Nov 12, 2017

See here for the underlying C-function:

/*
* Parses (almost) standard ISO 8601 date strings. The differences are:
*
* + The date "20100312" is parsed as the year 20100312, not as
* equivalent to "2010-03-12". The '-' in the dates are not optional.
* + Only seconds may have a decimal point, with up to 18 digits after it
* (maximum attoseconds precision).
* + Either a 'T' as in ISO 8601 or a ' ' may be used to separate
* the date and the time. Both are treated equivalently.
* + Doesn't (yet) handle the "YYYY-DDD" or "YYYY-Www" formats.
* + Doesn't handle leap seconds (seconds value has 60 in these cases).
* + Doesn't handle 24:00:00 as synonym for midnight (00:00:00) tomorrow
* + Accepts special values "NaT" (not a time), "Today", (current
* day according to local time) and "Now" (current time in UTC).
*
* 'str' must be a NULL-terminated string, and 'len' must be its length.
* 'unit' should contain -1 if the unit is unknown, or the unit
* which will be used if it is.
* 'casting' controls how the detected unit from the string is allowed
* to be cast to the 'unit' parameter.
*
* 'out' gets filled with the parsed date-time.
* 'out_bestunit' gives a suggested unit based on the amount of
* resolution provided in the string, or -1 for NaT.
* 'out_special' gets set to 1 if the parsed time was 'today',
* 'now', or ''/'NaT'. For 'today', the unit recommended is
* 'D', for 'now', the unit recommended is 's', and for 'NaT'
* the unit recommended is 'Y'.
*
* Returns 0 on success, -1 on failure.
*/

Note that it also supports the string "today" indicating a local time.

If we're going to document it, we should probably make sure that the functionality makes sense. In the most recent version of datetime64, we aim for compatibility with Python's datetime module (without timezones). So it's a little strange that "now" means UTC rather than local time (see https://docs.python.org/2/library/datetime.html#datetime.datetime.now) Arguably, we should use something different like "utcnow" for UTC.

The precision issue could potentially be improved, possibly by switching to rely on Python's time.time() rather than our own implementation. For now it would indeed make sense to document the (potentially) limited precision.

@mohdsanadzakirizvi
Copy link

Would like to work on this as my first contribution, is it open ?

@shoyer
Copy link
Member

shoyer commented Dec 24, 2017

As noted above, I think we should probably clean up this functionality before documenting it, which would encourage more people to rely on functionality that would likely change.

@gosuto-inzasheru
Copy link

Yeah the precision thing is quite misleading I think, passing 'ms' only increases the size of the float.

@Shreyjaradi
Copy link

I have raised an PR to add the example of np.datetime64("now", "ms")
#26477

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants