@Bibo-Joshi
I agree that the_to_timestamp helper should be moved to thetelegram.utils.helpers module. I have been working on that, but I came across some things I'd like to discuss before going forward. There are also some minor things which I will mention now that I've stopped.

1. There was already ato_timestamp helper in that module. It seems it is exclusively used to convertdatetime.datetime objects into integer timestamps to be sent in HTTP requests to Telegram's API.
   
   
   • To clear any ambiguity on the termtimestamp, I renamed some identifiers in such a way thattimestamp means "integer timestamp" (as I think that's what's usually meant when using that word) and explicitly usedfloat_timestamp to refer to timestamps with sub-second precision.
     
     Namely, I renamed the moved function toto_float_timestamp, and the former_timestamp helper (for the formertelegram.utils.helpers.to_timestamp) to_datetime_to_float_timestamp (to explicitly clarify that it only convertsdatetime.datetime objects). It is now used in theto_float_timestamp helper.
     
     
   • The originalto_timestamp function's name has been left the same, but its implementation has been redirected through the newto_float_timestamp for better maintainability. Now it also is able to convert any of the other relative time values (e.g.ints orfloats as "offset from a particular reference time").
     
     I don't know if you agree on that: as I said above, this function is only used in the repository to convert from adatetime.datetime to a timestamp, but not any of the other ways to specify time, as in thefirst argument fortelegram.ext.jobqueue.JobQueue.run_repeating. So, should restrict the usage ofto_timestamp todatetime.datetime objects? Or is it ok to allow the other types too?
     
     
     
2. There was inconsistent use of UTC vs local times. For instance, in the former_timestamp helper (now_datetime_to_float_timestamp), assumed that naïvedatetime.datetime objects were in the local timezone, while thefrom_timestamp helper —which I would have thought was the corresponding inverse function— returned naïve objects in UTC.
   
   This meant that, for instance,telegram.Message objects'date field was constructed as a naïvedatetime.datetime (from the timestamp sent by Telegram's server) inUTC, but when it was stored inJSON format through theto_json method, the naïvedate would be assumed to be inlocal time, thus generating a different timestamp from the one it was built from.
   
   So I sought to unify all handling of naïvedatetime.datetime by assuming they're always in UTC.
   
   
   • This, though, breaks the tests related to the parameterfirst ofJobQueue.run_repeating, since they assume that naïvedatetime objects are in local time. That makes me assume that users of PTB have been feeding localdatetime objects to this parameter, so changing it to UTC would break it for them. But I definitely believe that something has to be done about this: either we unify all naïvedatetimes to UTC or to local time. And since unifying to local would almost surely break backwards compatibility elsewhere, I think UTC is the better of the two options.
     
     
   • Maybe even better: ditch naïvedatetimes altogether and only work withdatetimes that have an explicittzinfo?
     
     
   • Finally, I also made sure thatdatetimes thatare timezone-aware are also treated validly.
     
     
   • With Python 2's lack of thedatetime.timezone class, and in particular, ofdatetime.timezone.utc, I had to "hard-code" a UTC singleton to use as atzinfo instance to indicate UTC. I wonder whether it would be better to move that to a new module, e.g.telegram.utils.datetime, since it's not a "helper" strictly speaking.
     
     
     
3. Besides the aforementioned timezone stuff, the original_datetime_to_float_timestamp had an issue of its own. The replacement method used to calculate the timestamp in Python 2 (in absence ofdatetime.datetime.timestamp) truncated the timestamp to an integer since that's the precision ofdatetime.datetime.timetuple/time.mktime. Of course, as it was before it didn't matter, but with the changes outlined in1. it does. So I replaced the alternative calculation with calculating a timedelta from the epoch and using.total_seconds() on it. At this point, I don't know if it's worth keeping the switch between Python 3.3+'sdatetime.datetime.timestamp and the alternative calculation, since the former's implementation is basically the same as the latter.
   
   
   
4. When the job queueticks, there is an inevitable delay between the exact time at which it was scheduled to peek and whentick is entered and the current time gets "frozen" (now = time.time()). Meaning that, for instance, if you set it to run every 5 seconds and stop runningafter 20 seconds from now, in theory it should run exactly five times: atΔt = 0s,Δt = 5s,Δt = 10s,Δt = 15s andΔt = 20s. But, in practice, when it gets to the fifth time, due to delays,Δt will be something like20 + 6.28e-5, meaning that if the code makes a strict comparison (Δt <= 20.0s), then the job won't be executed the fifth time.
   
   When I first made this PR, I thought that was undesired behaviour, so I added a "delay buffer" so that the check is more likeΔt <= 20.0s + ε, whereε is something like0.001s. But now that I think of it, I'd rather have the strict check, partly because of the fact that if the user needed to control the exact times the job was executed, they wouldn't use an end date/time, but rather something like counting up from within the callback; and partly because of the ugliness and arbitrary nature of setting adelay_buffer. In this case I'd rename the kwarg toend, since it indicates that after that time the job shouldn't run anymore — but the job won't necessarily run at the specified time for the last time.
   
   
   
5. Is this project going to keep supporting Python 2 for the next version? All of this compatibility handling and restraining oneself to older feature sets is a bit of a pain 😅

I realised that rambling on about the changes I've made without showing them is a bit useless. Tomorrow I'll push what I've got (we'll roll back if necessary). In any case, what do you think about all this?

Thank for your detailed report,@plammens !
For the discussion of the time related stuff, I'd like to move that to#1505 (or a corresponding PR). I guess, we'll have to think about that, before moving on with this one …

About4. : The way you put it, I tend to agree with your proposal about a strict check.

About 5.: We're looking to drop Python 2 support in version 13 (see#1538). Perhaps it makes sense to wait for that?

@plammens
would you like to rebas/merge this pr with the latest master so we can look at it with a fresh eye?

@tsnoam I've rebased this using the stuff introduced in#1506; I've also squashed a little.

I think now the only thing to discuss is4. (comment above). Do you agree that it should be a strict check? And thuslast should be renamed toend?

TL;DR: Closing in favor of#1981

After internal discussion, we came to the conclusion that we don't want to continue implementing scheduling logic on our own and instead rely on a 3rd party library for that (see#1936,#1981).
One of the upsides is, that alast keyword is already included.
We appreciate the effort that was put in this PR and hope that you'll find the newJobQueue useful once it's finished :)