Mailman 3 February 2020 - Datetime-SIG

Trouble to resolve a timezone offset to get correct UTC time
by Pierre 04 Jun '22

04 Jun '22

Hello, I am sorry, I am kind of lost and I would be really grateful to receive some help. Basically, I have a list of timestamps expressed as a strings as below, and I would like them expressed in UTC. But there seems to be a trouble during the offset, which is applied the other way round. The input timestamps look like: 0 'Sat Mar 30 2019 21:00:00 GMT+0100' Adding them in a panda dataframe with to_datetime function, they read then: GC['Time'] = pd.todatetime(my_timestamps) GC['Time'] 0 2019-03-30 21:00:00-01:00 If I further ask: GC['Time'][0] datetime.datetime(2019, 3, 30, 21, 0, tzinfo=tzoffset(None, -3600)) It seems, AFAIK, OK. But then if I want to resolve the offset so as to have time expressed in UTC time, I get: GC['Test'] = pd.to_datetime(GC['Time'],utc=True) 0 2019-03-30 22:00:00+00:00 The offset has bee applied the other way round. Correct timestamp in UTC would be 20:00:00 Please, what should I do to have these timestamps correctly expressed in UTC time? I thank you in advance for your help. I am so sorry to intrude the mailing list with this question, but I am unable to move forward from this point. I thank you again, Bests, Pierre

3 2

should utcnow and utcfromtimestamp return tz-aware?
by Brock Mendel 30 Dec '21

30 Dec '21

This has come up in pandas.Timestamp (which subclasses datetime). The issue is internal consistency and round-trips. Intuitively, we would expect: ``` a = datetime.utcnow() b = a.timestamp() c = datetime.utcfromtimestamp(b) assert a == b ``` but this fails. (Note: it works for `datetime.now()` with `datetime.fromtimestamp()`, though that is partially because of weird-to-me behavior of `timestamp()` for naive datetimes). It would succeed if utcnow and utcfromtimestamp returned tz-aware datetime objects. Thoughts?

7 12

PEP 615: Support for the IANA Time Zone Database
by Paul Ganssle 25 Feb '20

25 Feb '20

Greetings, Last year at the Language Summit, I proposed to add additional concrete time zones to the standard library ( https://pyfound.blogspot.com/2019/05/paul-ganssle-time-zones-in-standard.ht… ). After much work and much more procrastination, I now have now put together my first proposal: support for the IANA time zone database (also called tz, zoneinfo or the Olson database). I have submitted this for consideration as PEP 615 ( https://www.python.org/dev/peps/pep-0615/ ), and I have created a discussion thread for the PEP on the discourse forum ( https://discuss.python.org/t/pep-615-support-for-the-iana-time-zone-databas… ). Please give it a read and provide your constructive criticism. I have documented my reasoning for most of the design decisions, but I am very interested in getting feedback on the choices I’ve made here. I have marked two sections as “Open issues”, as they are the ones I feel most uncertain about, but all parts of it are up for discussion. For the purposes of centralizing discussion, please direct comments to the discourse thread <https://discuss.python.org/t/pep-615-support-for-the-iana-time-zone-databas…>. _*Links for easy access:*_ *Discussion:* https://discuss.python.org/t/3468 *PEP:* https://www.python.org/dev/peps/pep-0615/ *Reference Implementation:* https://github.com/pganssle/zoneinfo *tzdata repo:* https://github.com/pganssle/tzdata (Note: At some point I plan to move the tzdata repo to github.com/python/tzdata; if the reference implementation turns into a backport that will likely also move to an org as well). Thanks for your consideration! Paul

1 0