Every week, my school makes us type which assignments we will be doing for the week. I want to do this automatically with python.
Below is a example of what an input I might want the program to take.
Unit 1 presentation - Due in 2 days - 40 minutes spent
English Unit 2 Test - Due in 3 days - 1 hour spent
History Essay - Due in 7 days - 10 minutes spent
I want to get rid of everything other than the name of the assigments. How can I achieve this? I can't simply use the find() method since the substrings may vary.
Google hasn't been much help. I'm a beginner, so please bear with me.
I would try to take each line as line and process as
assignment_name = line.split("-")[0].strip()
I'm having trouble making column into a date time column when I have a column with Minutes and Seconds (example, 210:39:00 ,29:23:00) I have no interest in converting into hours, as it would make very little sense to do so within the context of the purpose of the code. Everything I have found is converting the minutes into hours, Id like to keep a format with just minutes and seconds. From the example "210:39:00" the first number is total minutes, the second number is seconds, the last number is nano seconds. it is a string currently; I would convert to a datetime column with the format %M;%S:%f. I have found no way to do this without transforming the first number which is minutes to hours. I would like to keep total minutes and seconds
If you're trying to store this in a Datetime in the DB then this isn't really a feature of this type. I would suggest either storing a minutes and seconds column as an int or maybe storing total seconds, then in your code doing the maths to create whatever you are displaying
I have a dataset that looks as follows:
What I would like to do with this data is calculate how much time was spent in specific states, per day. So say for example I wanted to know how long the unit was running today. I would just like to know the sum of the time the unit spent RUNNING: 45 minutes, NOT_RUNNING: 400 minutes, WARMING_UP: 10 minutes, etc.
I know how to summarize the column data on its own, but I'm looking to reference the time stamp I have available to subtract the first time it was on, from the last time it was on and get that measure of difference. I haven't had any luck searching for this solution, but there's no way I'm the first to come across this and know it can be done some how, just looking to learn how. Anything helps, Thanks!
I am trying to solve the following problem. I have a code where there is an event and it is connected to a time in seconds. I am attaching this to video so I need a lead and a lag time. I am able to create the lead time, but for some of the events, the lag time is correlated to when the next event occurs.
For example, a shot has a lead time of 3 and a lag time of 7. However, for zone time, I need to create a lead time of 3 and a lag time of next occurrence of the title 'whistle'.
While reviewing my past answers, I noticed I'd proposed code such as this:
import time
def dates_between(start, end):
# muck around between the 9k+ time representation systems in Python
# now start and end are seconds since epoch
# return [start, start + 86400, start + 86400*2, ...]
return range(start, end + 1, 86400)
When rereading this piece of code, I couldn't help but feel the ghastly touch of Tony the Pony on my spine, gently murmuring "leap seconds" to my ears and other such terrible, terrible things.
When does the "a day is 86,400 seconds long" assumption break, for epoch definitions of 'second', if ever? (I assume functions such as Python's time.mktime already return DST-adjusted values, so the above snippet should also work on DST switching days... I hope?)
Whenever doing calendrical calculations, it is almost always better to use whatever API the platform provides, such as Python's datetime and calendar modules, or a mature high-quality library, than it is to write "simpler" code yourself. Date and calendar APIs are ugly and complicated, but that's because real-world calendars have a lot of weird behavior.
For example, if it is "10:00:00 AM" right now, then the number of seconds to "10:00:00 AM tomorrow" could be a few different things, depending on what timezone(s) you are using, whether DST is starting or ending tonight, and so on.
Any time the constant 86400 appears in your code, there is a good chance you're doing something that's not quite right.
And things get even more complicated when you need to determine the number of seconds in a week, a month, a year, a quarter, and so on. Learn to use those calendar libraries.
Number of seconds in a day depends on time system that you use e.g., in POSIX, a day is exactly 86400 seconds by definition:
As represented in seconds since the Epoch, each and every day shall be
accounted for by exactly 86400 seconds.
In UTC, there could be a leap second included i.e., a day can be 86401 SI seconds (and theoretically 86399 SI seconds). As of Jun 30 2015, it has happened 26 times.
If we measure days by apparent motion of the Sun then the length of a (solar) day varies through the year by ~16 minutes from the mean.
In turn it is different from UT1 that is also based on rotation of the Earth (mean solar time). An apparent solar day can be 20 seconds shorter or 30 seconds longer than a mean solar day. UTC is kept within 0.9 seconds of UT1 by the introduction of occasional intercalary leap seconds.
If you define a day by local clock then it may be very chaotic due to bizarre political timezone changes. It is not correct to assume that a day may change only by an hour due to DST.
According to Wikipedia,
UTC days are almost always 86 400 s long, but due to "leap seconds"
are occasionally 86 401 s and could be 86 399 s long (though the
latter option has never been used as of December 2010); this keeps the
days synchronized with the rotation of the Earth (or Universal Time).
I expect that a double leap second could in fact make the day 86402s long, if that were to ever be used.
EDIT again: second guessed myself due to confusing python documentation. time.mktime always returns UTC epoch seconds. There done. : )
In all time zones that "support" daylight savings time, you'll get two days a year that don't have 24h. They'll have 25h or 23h respectively. And don't even think of hardcoding those dates. They change every year, and between time zones.
Oh, and here's a list of 34 other reasons that you hadn't thought about, and why you shouldn't do what you're doing.