This question already has an answer here:
How to get the first datetime of a day?
(1 answer)
Closed 7 years ago.
I wonder if there's any way to get the UNIX timestamp at the beginning of a certain day, i.e the midnight timestamp of each day given its timezone.
Assuming you do not care about daylight savings time and you know the UTC offset which was in effect at that time (as opposed to the UTC offset which is in effect now), you can just do this:
import datetime as dt
return dt.datetime(year, month, day, tzinfo=dt.timezone(utc_offset)).timestamp()
The hour, minute, and second default to zero, so you can skip them. The timezone class does not handle daylight savings time, historical changes in timezone definitions (e.g. British Double Summer Time), or any other temporal anomalies (e.g. there was no December 30, 2011 in Samoa); it is a "dumb" offset. It is equivalent (in this case) to adding or subtracting the offset directly onto the timestamp and then working in UTC. You must ensure this is correct for your use case. If you need better timekeeping, you should install and make use of pytz.
Related
I need to get the current offset on any timezone in Python. At the moment I am using the pytz library and I am getting the offset with this code:
import datetime
import pytz
timezone = 'America/Punta_Arenas'
datetime.datetime.now(pytz.timezone(timezone)).utcoffset().total_seconds()/60/60
//prints -3
timezone = 'America/Santiago'
datetime.datetime.now(pytz.timezone(timezone)).utcoffset().total_seconds()/60/60
//prints -4
Taking as example 'America/Santiago': this year (2018), DST was set the 13 of May, while in 2015 DST was observed the whole year and in 2014 was set the 27 of April. So, sepending on the date and the year the offset is '-3' or '-4'.
I assume the previous code is not aware of the political decisions of each country regarding DST and probably gets you the offset according to fixed DST dates or something like that. Since I do not know how the nuts and bolts of datetime and pytz I'd rather ask, is this assumption right?
If it is not aware, how can I get the real current offset for any timezone?
I assume the previous code is not aware of the political decisions of each country regarding DST and probably gets you the offset according to fixed DST dates or something like that.
Your assumption is incorrect. Political changes of time zones are recorded and distributed via the TZ Database. Those changes are then implemented in hundreds of different libraries, platforms, and operating systems - such as the pytz library you mention.
The change to America/Santiago that you describe was reflected in TZDB 2016c, which is implemented in pytz 2016.3. If you are using pytz 2016.3 or greater, then your code is aware of this change.
Pytz is fine, but you may want to consider using dateutil instead. Version 2.5.2 or higher has this data.
Having a hard time searching for this since it's mostly datetime or similar-but-different results and still seeming to struggle with getting suggestions for slightly different problems to work with this one.
I have some UTC datetime object: timestamp. What I'm doing is dealing with many timestamps and corresponding values and bucketing them hour by hour, so I'm bucketing them by timestamp.timetz().
Now I want to loop through these buckets, take this UTC time object, and convert it to Eastern time, e.g. I want 00:00 to become 20:00, keeping daylight savings in mind.
How do I accomplish this?
You can use the "pytz" package to get this done. Below is a example to get current time using pytz in eastern timezone.
import pytz
from datetime import datetime
est_tz = pytz.timezone('US/Eastern')
datetime.now(est_tz)
Hope it helps.
Happy Coding !! :)
I would like to set the expiry time for memcache objects to a specific date.
cache.set(string, 1, 86400)
The statement above allows me to set it for a day, but it does not expire if the date changes. One way I could handle this is by calculating the number of seconds left in the day and provide it as a variable.
I was wondering if there was a more simpler/efficient way to do it.
Looking at the documentation, we see that the expiration parameter is explained as:
Optional expiration time, either relative number of seconds from current time (up to 1 month), or an absolute Unix epoch time. By default, items never expire, though items may be evicted due to memory pressure. Float values will be rounded up to the nearest whole second.
So basically if the number you put in there is less than 2592000, it is interpreted as a relative time. So the number 86400 would be interpreted as 86400 seconds (one day) from now, the time it's being set.
It looks like you're going to want to use a number bigger than that to signify an absolute time. There are a variety of ways to get a unix timestamp. But quite simply you can do:
time_tuple = (2013, 2, 15, 0, 0, 0,0,0,0)
timestamp = time.mktime(time_tuple)
cache.set(string, 1, timestamp);
You initial idea is correct. You can find out the timestamp for now, and the timestamp of the date you want and just provide the difference, that would be equivalent too.
The day changes at least every hour of every day, does it not? Either the client or the server must specify which one of those is relevant to any given request. This is generally a better task for the client application.
Do note that you can specify absolute timestamps, which might make it easier to calculate when that expiry time is since you'd be able to reuse it for the whole day (or at least an hour).
I have a date(datetime) which is stored in the database as GMT time.
I need to convert this to local time.How can i achieve this using python
Please have your suggestions
Thanks in Advance!!
Have you read the Python documentation, 8.1 datetime — Basic date and time types
and especially 8.3 tzinfo objects?
They describe the library function datetime.astimezone(tz=None), which may be exactly what you want.
Return a datetime object with new tzinfo attribute tz, adjusting the date and time data so the result is the same UTC time as self, but in tz‘s local time.
They have example code there for defining a time zone in terms of an offset from UTC, ending with a declaration like:
Pacific = USTimeZone(-8, "Pacific", "PST", "PDT")
Having read that, what is your question?
Do you have a date or a datetime? i.e. does the data have a time zone component? If no time component, then what is the meaning of changing the date to a different time zone?
Do you have a 'naive' or 'aware' datetime? From the docs,
An aware object has sufficient knowledge of applicable algorithmic and political time adjustments, such as time zone and daylight saving time information, to locate itself relative to other aware objects. An aware object is used to represent a specific moment in time that is not open to interpretation....
A naive object does not contain enough information to unambiguously locate itself relative to other date/time objects. Whether a naive object represents Coordinated Universal Time (UTC), local time, or time in some other timezone is purely up to the program, just like it is up to the program whether a particular number represents metres, miles, or mass. Naive objects are easy to understand and to work with, at the cost of ignoring some aspects of reality.
The Python documentation is really quite good. Perhaps it will answer your questions without you having to ask StackOverflow.
I'm storing MySQL DateTimes in UTC, and let the user select their time zone, storing that information.
However, I want to to some queries that uses group by a date. Is it better to store that datetime information in UTC (and do the calculation every time) or is it better to save it in the timezone given? Since time zones for users can change, I wonder.
Thanks
Generally always store in UTC and convert for display, it's the only sane way to do time differences etc. Or when somebody next year decides to change the summer time dates.
It's almost always better to save the time information in UTC, and convert it to local time when needed for presentation and display.
Otherwise, you will go stark raving mad trying to manipulate and compare dates and times in your system because you will have to convert each time to UTC time for comparison and manipulation.