Python:将UTC时间元组转换为UTC时间戳 [英] Python: Convert UTC time-tuple to UTC timestamp

查看:168
本文介绍了Python:将UTC时间元组转换为UTC时间戳的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的问题:我需要将UTC时间元组转换为UTC时间戳。但是我有一些混淆。

My problem: I need to convert a UTC time-tuple into a UTC timestamp. But I have some confusions.

首先有一个信息:


  • time.mktime(tuple):此函数始终返回本地时间中的时间戳。

  • time.mktime(tuple): this function always returns the timestamp in local time.


这是localtime()的反函数。它的参数是struct_time或完整的9元组,表示在本地时间,而不是UTC的时间。


  • calendar.timegm(tuple):这将从提供​​的时间元组

  • calendar.timegm(tuple): this returns the UTC timestamp from the supplied time tuple


    采用时间模块中由gmtime()函数返回的时间元组,并返回相应的Unix时间戳记值。实际上, time.gmtime()和timegm()是彼此的逆向


  • 现在让我们进行一个测试:

    Now let's do a test:

    >>> from datetime import datetime
    >>> import time
    >>> import calendar as cal
    
    >>> utc_now = datetime.utcnow()
    >>> now = datetime.now()
    >>> utc_now
    datetime.datetime(2013, 3, 16, 9, 17, 22, 489225)
    >>> now
    datetime.datetime(2013, 3, 16, 5, 17, 29, 736903)
    
    >>> time.mktime(datetime.timetuple(utc_now)), time.mktime(datetime.timetuple(now))
    (1363439842.0, 1363425449.0)
    >>> cal.timegm(datetime.timetuple(utc_now)), cal.timegm(datetime.timetuple(now))
    (1363425442, 1363411049)
    

    为什么有四种不同的值?当我想将UTC时间元转换为UTC时间戳时,哪一个是正确的?

    Why are there four different values? And which one is right when I want to convert a UTC time-tuple into a UTC timestamp?

    UPDATTE

    UPDATTE

    我想我已经找到了我的困惑的答案,所以让我解释一下。

    I think I have found answers to my confusions, so let me explain.

    首先,我们需要知道一些重要的东西:

    First, we need to know something important:


    有两种日期和时间对象:天真和感知。

    There are two kinds of date and time objects: "naive" and "aware".

    感知对象具有足够的应用算法和政治时间调整的知识,如时区和夏令时信息,可以相对于其他位置定位自身感知对象。一个感知对象用于表示一个不能解释的特定时刻[1]。

    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 [1].

    一个天真的对象不包含足够的信息来明确地定位自己的相对到其他日期/时间对象。 无论是天真的对象代表协调世界时(UTC),当地时间还是其他时区的时间完全取决于程序,就像程序一样,特定的数字是否代表米,英里,或大量。 天真的对象易于理解和使用,代价是忽略现实的某些方面。

    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.

    我们从 datetime.utcnow() datetime.now()获得的是天真的对象。这意味着返回的 datetime 对象在任何时候都不会说出你的本地时间或UTC时间 - 它只是表示一段时间。它只是封装了日期&时间信息(年,月,日,时,分,秒等)。您有责任将其与本地或UTC的概念相关联。

    What we get from datetime.utcnow() or datetime.now() are "naive" objects. This means that the datetime object that is returned does not, in anyway, say anything about your local time or UTC time -- it just represents "some time". It just encapsulates date & time information (year, month, day, hour,minutes, seconds, etc.). It is YOUR responsibility to associate it with the notion of local or UTC.

    所以,请记住,一个天真的datetime对象只是表示一段时间。 datetime.now()函数返回等于您当前时间的一段时间,而$ code> datetime.utcnow()函数返回格林威治英格兰当前时间的一些时间(这是UTC是什么)。

    So, remember that a naive datetime object just represents "some time". The datetime.now() function returns a "some time" that is equal to your current time, and the datetime.utcnow() function returns "some time" that is the current time in Greenwich England (which is what UTC is).

    某个时间只是一个值日期&时间。并注意到,在不同的地方,一段时间发生在不同的时期。例如,如果一些时间值是1月1日,10:30,比现在在格林威治时间的时间大约5小时,之后它将成为纽约当前时间。

    The "some time" is just a value for date & time. And note that on different locations on earth, the "some time" occurs on different times. For example, if a "some time" value is January 1, 10:30, than it will be the current time in Greenwich England some 5 hours BEFORE it becomes the current time in New York.

    因此,我们可以看到有两件事情:一般的一段时间的价值,以及不同的时间在不同的时间在不同的地点成为当前时间的概念。 (没有双关语在这里阅读)

    Hence we can see that there is two things: a generic "some time" value, and the notion that that "some time" becomes current time at different locations at different "times". (no pun here, read on)

    现在,我们先来定义什么是纪元。我们知道一段时间只是时间的通用价值。那么,这个时代是在格林威治英格兰发生的一段时间,参数的值是: 1970年1月1日00:00:00

    Now, let's first define what is "epoch". We know that "some time" is just a generic value of time. Then, the epoch is a "some time" that occurred in Greenwich England where the values of the parameters are: January 1 1970, 00:00:00.

    时间戳是否。从史诗以来已经过去的秒数。这意味着,时间是 0 当时间是在$格林威治时间1970年01月01日00:00:00 。但是时间戳是大约。 (5 * 60 * 60)当时间是 1970年1月1日,00:00:00 在纽约。

    A "timestamp" is no. of seconds that have elapsed since epic. This means that the timestamp was 0 when the time was Jan 1, 1970, 00:00:00 in Greenwich England. But the timestamp was approx. (5 * 60 * 60) when time was Jan 1, 1970, 00:00:00 in New York.

    >>> tt = datetime.timetuple(datetime(1970, 1, 1, 0, 0, 0))
    >>> cal.timegm(tt)
    0
    

    因此,我们可以看到同样的一些时间值 1970年1月1日,00:00:00 在更改位置时具有不同的时间戳。因此,当你谈论时间戳时,你还需要说什么位置是与时间戳相关的,以及该位置与格林威治英格兰有多少东西方向。该位置被表示为时区。

    Thus, we can see that the same "some time" value of Jan 1, 1970, 00:00:00 has different timestamps when we change locations. Hence when you talk about timestamp, you need to also say "what location" is the timestamp related to, and how much eastward or westward that location is related to Greenwich England. That location is expressed as a "timezone".

    现在,每个系统(计算机)都配置了时区,与该时区相关的所有时间戳都成为本地 。 UTC是全球参考。

    Now, every system (computer) has a timezone configured, and all timestamps related to that timezone effectively become the "local". The UTC is the global reference.

    所以,假设你有一个 X 转换为:

    So, let's say you have an X value for "some time" which converts to:


    • Y 当地时间的时间戳

    • Z UTC时间戳

    • Y timestamp in your local time
    • Z timestamp in UTC

    那么这意味着 Y no。秒数必须经过一段时间才能成为您所在位置的当前时间,而 Z 不需要几秒钟就能通过目前在格林威治时间的时间成为一段时间。

    then this means that Y no. of seconds will have to elapse for "some time" to become the current time in your location and Z no of seconds will have to pass in order for current time in Greenwich England to become "some time".

    最后,我们回到我们的函数 mktime timegm 。这些需要一个时间元组,这只是一段时间的另一个代表。记住,我们传递他们一个天真的时间,没有任何本地或UTC的概念。

    Now, finally, let's come back to our functions mktime and timegm. These take a time-tuple, which is just another representation for "some time". Remember that we're passing them a naive time which does not have any notion of local or UTC.

    让我们说 X 是一个代表天真的一段时间的时间元组。然后

    Let's say X is a time-tuple representing a naive "some time". Then


    • mktime(X)将返回否。必须经过的秒数,以便您当地的当前时间成为一段时间,而

    • timegm(X)将返回必须花费的秒数,使当前格林尼治时间的格林尼治标准时间等于一段时间。

    • mktime(X) will return the no. of seconds that will have to elapse in order for your local current time to become that "some time", and
    • timegm(X) will return the no of seconds that will have to be spent to make the current time of Greenwich England equal to that "some time".

    在上面的例子中,现在 utc_now 表示天真的一段时间,当我们将这些一些时间值提供给 mktime timegm 时,他们只是返回no 。的秒数,必须通过相应的位置(您的位置和格林威治英格兰),以使他们当前的时间是一段时间。

    In the example above, now and utc_now represent naive "some time", and when we feed these "some time" values into mktime and timegm, they simply return the no. of seconds that have to pass for the corresponding locations (your location and Greenwich England) to have their current time be that "some time".

    最后,回到我的问题:我需要将UTC时间元转换为UTC时间戳。

    Finally, back to my problem: I need to convert a UTC time-tuple into a UTC timestamp.

    首先,没有UTC的概念时间元组 - 这只是一段时间。如果我需要将其转换为UTC,我只需使用 timegm

    Firstly, there is no concept of "UTC time-tuple" -- it's just "some time". If I need to convert it to UTC, I simply use timegm:

    cal.timegm(datetime.timetuple(utc_now))
    

    这将给我当前的时间戳UTC时间(即格林尼治英格兰当前的一段时间)。

    which will give me the timestamp for the current UTC time (i.e., the current "some time" in Greenwich England).

    推荐答案

    / em>不同的值。这两个值:

    There are effectively only three different values. These two values:

    1363425449.0 (time.mktime(datetime.timetuple(now))
    1363425442   (cal.timegm(datetime.timetuple(utc_now)))
    

    只有7秒不同,这是你最初看到的当您转储变量时:

    only differ by 7 seconds, which is what you originally saw when you dumped the variables:

    >>> utc_now
    datetime.datetime(2013, 3, 16, 9, 17, 22, 489225)
    >>> now
    datetime.datetime(2013, 3, 16, 5, 17, 29, 736903)
    

    (注意输出秒数中的22对29)。

    (Note the 22 vs 29 in the seconds part of the output.)

    其他两个值都是错误的,因为您使用了错误的参数 - 您使用UTC值而不是本地值调用 time.mktime ,而您使用本地值而不是UTC值调用 cal.timegm 。文档清楚地说明了预期的 - 所以请确保只使用适当的值,您基本上看到了当地时间偏移(4小时,乘t他看起来)被应用于不应该(在不同的方向取决于错误在哪里)。

    The other two values are simply erroneous, because you're applying the wrong kind of arguments - you're calling time.mktime with UTC values instead of local values, and you're calling cal.timegm with local values instead of UTC values. The documentation clearly says what's expected - so make sure you only use the appropriate values. You're basically seeing your local time offset (4 hours, by the looks of it) being applied when it shouldn't be (in different directions depending on where the error is).

    当你诊断这样的事情,它是有助于使用 epochconverter.com ,这将为您提供当前的Unix时间戳,因此您可以将其与输出进行比较。

    When you're diagnosing things like this, it's helpful to use epochconverter.com which will give you the current Unix timestamp, so you can compare it with your output.

    这篇关于Python:将UTC时间元组转换为UTC时间戳的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

    查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆