Comments (11)
Hum, the alternative is to use datetime.utcnow()
I guess.
But good point.
from jupyter_client.
Actually, datetime.utcnow()
still doesn't return a timezone-aware datetime object (I've no idea why, really, UTC seems simple enough that it could be part of standard library, but hey ho). To remove dependency on pytz, something like this SO answer, which defines a tzinfo class for UTC, might be a better solution...
from jupyter_client.
see, for reference, the difference in the two print statements from this snippet:
from datetime import datetime, timedelta, tzinfo
TDZERO = timedelta(0)
class UTC(tzinfo):
"""A UTC tzinfo class"""
def utcoffset(self, dt):
return TDZERO
def tzname(self, dt):
return 'UTC'
def dst(self, dt):
return TDZERO
utc = UTC()
print('utcnow', datetime.utcnow().isoformat())
print('tz=utc', datetime.now(tz=utc).isoformat())
gives
utcnow 2016-03-21T19:03:04.625622
tz=utc 2016-03-21T19:03:04.625970+00:00
from jupyter_client.
Actually, datetime.utcnow() still doesn't return a timezone-aware datetime object (I've no idea why, really, UTC seems simple enough that it could be part of standard library, but hey ho)
Sorry I was unclear in my statement, we could normalize the spec saying that the date time should be UTC if the current spec is not precise enough.
Of course for backward compatibility we should encourage people to have timezone, but I think in the long term, having UTC everywhere (execpt on user facing UI) make sens.
from jupyter_client.
Right, gotcha. Still, I think it's worth adding the timezone to the string values as well, rather than just altering the spec to allow people to assume they're in UTC - after all Explicit is better than implicit 😉
from jupyter_client.
We already have three copies of the machinery to produce tz-aware UTC timestamps - there's one in jupyter_client, but it's currently in the tests (test_jsonutil
to be precise). I'm pretty sure that UTC timestamps are the way to go, not localised timezone-aware timestamps.
from jupyter_client.
Oh absolutely, utc is the way forward, I just meant the offset (of zero, naturally) should get included in the json-ified text version, as with the utcnow
in test_jsonutil
.
from jupyter_client.
Oh absolutely, utc is the way forward, I just meant the offset (of zero, naturally) should get included in the json-ified text version, as with the utcnow in test_jsonutil.
Do I smell a Pull Request coming ?
from jupyter_client.
Haha 😆 I'm happy to submit one, I was a little apprehensive of adding yet another mechanism to produce tz-aware timestamps! If you guys know where you'd like to put it, I'll be happy to fix it up...
from jupyter_client.
We can have nice tz-aware utc timestamps with the stdlib in Python 3 with:
datetime.datetime.now(datetime.timezone.utc)
Python 2, of course, needs an backport of the trivial UTC timezone, which we have implemented here (and elsewhere). We can use utc for that, I suppose.
from jupyter_client.
master (will be 5.0) uses timezone-aware datetimes.
from jupyter_client.
Related Issues (20)
- Use Cases for `silent=True`
- How to get kernel_id from a running Python kernel? HOT 1
- Exposing kernel contents (file system) via comms HOT 4
- Questions about the debug message spec HOT 1
- Update wrapperkernels documentation
- deprecate automatically parsing header timestamps
- Add `jupyter kernelspec list/remove --missing` to list/remove all missing kernels.
- Question: How can I make the code completer recognize extra namespace?
- DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguious HOT 2
- zmq.Poller is not async HOT 1
- Compatibility issues with requests library HOT 1
- Exception raised in KernelClient.del when shutting down kernel after executing code using kc.execute_interactive() HOT 2
- Jupyter run app TIMEOUT HOT 2
- Kernels dies immediately due to library name collisions HOT 5
- Clarification of `history_request` status and future plans HOT 1
- Weird failures in `jupyter_client` with jupyter_core 5.3.2 HOT 2
- Getting the first element of entrypoints results in a KeyError
- 8.5.0: pytest is failing in two units HOT 5
- multikernelmanager update_env error HOT 3
- When no kernel is found, jupter-run crashes with a traceback HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jupyter_client.