Open danielhoherd opened 8 years ago
I just rediscovered this bug when using jrnl
, then discovered that I had already filed it! I have verified on macOS and Linux that this is still a problem in jrnl version jrnl==1.9.8 which is the latest available through pip.
+1
Did some reading. Python doesn't support timezones in the stdlib. https://stackoverflow.com/questions/4530069/python-how-to-get-a-value-of-datetime-today-that-is-timezone-aware
jrnl doesn't do this but with the above article for saving the entries and this article for displaying them, this should be pretty easy: https://stackoverflow.com/questions/13218506/how-to-get-system-timezone-setting-and-pass-it-to-pytz-timezone
for me this works just fine:
from datetime import datetime
TIMEZONE_LOCAL = datetime.now().astimezone().tzinfo
...
timestamp = datetime.now()
if timestamp.tzinfo is None:
timestamp = timestamp.replace(tzinfo=TIMEZONE_LOCAL)
According to @micahellison (in #630), this was a limitation of Python until 3.2. Now that we're moving on from Python 2, we'll be able to add proper %z
support soon. We have some date reworking coming down the line, so this will probably be part of that.
@wren What's the timeline for the time changes :)
@dftchfmstrpnk This issue isn't scheduled in a milestone yet, but PRs are welcome if anyone wants to try to get this into a sooner release.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
SRSLY??
@artgromov Hi! You seem to care about this feature quite a bit. I understand that it can be frustrating to see something you care about not get the attention you'd like. We try to prioritize the features that users care about, but not everything can make it in all at once (remember that we only have so much time, and this is unpaid work).
So, as I mentioned above, this feature isn't currently scheduled. If you would like to see it in the project sooner than when we have time to work on it, please send us a PR. PRs are the best and fastest way to get a feature you care about into this project. Please be sure to reference this issue number in your PR so the reviewer has more context about the work.
That all being said, I would like to address your comment above. "SRSLY??" is an unprofessional and disrespectful response. I invite you to review our code of conduct. Please use this as a guide for your future comments in this project.
Sorry I didn't mean to seem disrespectful at all.
I was frustrated because of "drop the issue when it becomes stale" policy. This policy severely decreases the project's chances to improve in the future.
This policy severely decreases the project's chances to improve in the future.
No, it makes sure only issues people care about stay open, so that maintainers and other contributors don't waste their time implementing stuff that might be not needed anymore. It helps the project focus on what's important.
jrnl does not appear to support the %z (timezone offset) strftime directive in its time format.