I recently started using imapclient in order to fetch emails from my Yahoo! account. The program is relatively simple. It is as follows:
yahoo=imap.IMAPClient('imap.mail.yahoo.com', ssl=True)
yahoo.login('myusername', 'mypassword')# cant tell you my username and password, can I?
yahoo.select_folder('Inbox', readonly=True)
# so far, everything is going fine.
yahoo.search(['ON 1-Nov-2015'])
Here's the problem. I've already received tons of messages on November 1st, and the method returns []. It does not work on any date I try. It's as if the 'ON' search doesn't work at all. So I try another method.
yahoo.search(['SINCE 1-Nov-2015'])
No matter how many times I restart the program, less than the actual amount of email UIDs are returned. So I investigate, and I think this may be the problem:
yahoo.fetch(11636, 'BODY[]')
11636 was an email that has a timestamp 10:20 AM, November 1. Instead, the return value says that it was received at 2:20 AM, November 1. I believe this is the problem.
Maybe I am mistaken, and that is the problem. Maybe I am doing something terribly wrong. Either way, any help or suggestions would be greatly appreciated.
I used datetime to make it work
import datetime
yahoo.search([u'SINCE', datetime.date(2015, 11, 1)])
Kind of a late answer, sorry for that :/
I think ON and SINCE are probably using UTC, whereas the time zone you see in the header is in (some) local time. Try querying according to UTC and see if you get the results you expect.
Related
im trying to retrieve the date and time of a message, and the date is correct, but the time is about 6 hours off. how can i fix this?
it is 5pm currently, but this line of code returns 23:00
msgDate = update.message.date
edit: it is returning the minutes properly, so its close, just not sure on what to do about the hours.
It seems as though function built into python-telegram-bot uses the UTC timezone, so yes, it does return the proper date and time, just converted into UTC
I'm need to save the time that some task took to the user to finish it.
For example, suppose you have to answer a couple of questions of an exam. If you started at 10:00 am and finish it at 11:00am I'd like to store the time it took you to finish it. In this case it'd be 1hr or 60 minutes, or 3600 seconds.
After that i'd like to display that in a pretty way. Suppose something took 527 seconds, i'd like to show: 8'47. So i'd need some template tag to do the work.
Of course i've seen TimeField, but it's using datetime.time, and I don't think it's the rigth fit for this situation.
I've also analized using just an IntegerField storing seconds (that level of detail is Ok). But maybe you guys know a better option.
Thank you!
An integral field storing seconds is probably best for storing durations (it's easy to then plug that into a timedelta). Of course, if you think you might want to store fractions of a second in the future, you might want to consider making it a float field instead.
You could also subclass either IntegerField or FloatField and make a version that automatically translates the contents to and from a timedelta automatically... or use one that someone's created already.
In Python, I want a Python program to be able to determine the current date and time in NYC . Is that practical? While datetime.datetime.now() can tell me the local time, and datetime.utcnow() can tell me the UTC (GMT). However just looking at the difference will not help me as DST changes.
I try things like "dt=datetime.now() " and "dt.timetuple()"
I get tm_isdst=-1 even if I change the computer date.
I change my computer clock from a January date to a July date. I still get tm_isdst=-1
Why not use pytz? I want the users to not have to go thru the step of downloading an extra library.
I suspect some sort of problems in your use of the datetime, time, etc. modules, but without knowing more, not much help can be provided.
The following suggestion has some definite drawbacks, and I really recommend more pursuit to solving the problems with datetime, etc. However, if you're sure to have a web connection and need to get something done fast, you could query USNO time with something like:
import urllib
f = urllib.urlopen("http://tycho.usno.navy.mil/cgi-bin/timer.pl")
time_page = f.readlines()
for line in time_page:
if line.find("Eastern Time") != -1:
ny_time = line[4:24]
break
print ny_time
The output looks like:
Jan. 19, 05:18:04 PM
This makes use of the fact that NYC is in the Eastern Time zone. Also, it assumes the USNO server is available to your user. Furthermore, it has assumptions about the format of the content returned. I don't know if/how frequently that format changes. Also, if this is going to be used a lot, please find another server, as you don't want to sink the USNO server! (Pun not originally intended, but recognized and kept. :-).
If you are not in the same timezone as NYC, it's in practice impossible without knowing the timezone and when DST changes. You can't hardcode it for NYC, of course, but it is way easier to just install pytz or dateutil, and then you aren't limited to NYC.
I'm working on making a small ban system, and the snippet below will tell the client how much time of their ban is remaining.
The problem:
When you call Bans.timeleft_str(), rather then showing something less then a day, it will show the timestamp + 18 hours.
Snippet: http://pastebin.com/Zumn0tLv
This problem occurs if I change self.length = WEEK, etc. Rather then 7d 00h 00m, it will be 7d 18h 00m.
I originally tested this on my ubuntu vbox, and then tried it on my windows python shell, and still got the same result.
You may need to change self.timestamp to a time in the past.
Thanks in advance.
time.time, as the docs I just pointed to say, works in UTC (once known as "Greenwich" time, now "universal time coordinate"). mktime, again as said in its docs, takes as argument
9-tuple [...] which expresses the time in local time, not UTC.
strptime may work either way (but you're not supplying a timezone, so it's going to use local time).
So, overall, you're getting deep into timezone confusion;-).
I recommend (as always) that you standardize on UTC (the local timezone of your server can well not be the same as that of its users, after all), e.g. with a %Z directive in the format you pass to strptime and a corresponding timezone of 'UTC' (which is guaranteed to be recognized on all platforms) in the corresponding part of the string you're parsing.
I currently have setup a Python script that uses feedparser to read a feed and parse it. However, I have recently come across a problem with the date parsing. The feed I am reading contains <modified>2010-05-05T24:17:54Z</modified> - which comes up in Python as a datetime object - 2010-05-06 00:17:54. Notice the discrepancy: the feed entry was modified on the 5th of may, while python reads it as the 6th.
So the question is why this is happening. Is the ATOM feed (that is, the one who created the feed) wrong by putting the time as 24:17:54, or is my python script wrong in the way it treats it.
And can I solve this?
There are some interesting special cases in the rfc here (https://www.rfc-editor.org/rfc/rfc3339), however, typically its for the 00:00:60 vs 00:00:59 to allow for leap seconds. It may be though that that is legal. My guess is that its doing the "right thing". In all honesty, date/time things get really messy due to things like DST and local timezones. If its 24:17:54, that might be the right thing after all.
I think today at 24:17 is intelligently parsed as tomorrow at 00:17.... I'm thinking you are well handling the producer's bug.