[issue43484] we can create valid datetime objects that become invalid if the timezone is changed

[Éric Araujo]

Change by Éric Araujo :


--
nosy: +eric.araujo
versions:  -Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43484] we can create valid datetime objects that become invalid if the timezone is changed

[Zachary Ware]

Change by Zachary Ware :


--
nosy: +belopolsky, lemburg, p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43484] we can create valid datetime objects that become invalid if the timezone is changed

[mike bayer]

New submission from mike bayer :

So I'm pretty sure this is "not a bug" but it's a bit of a problem and I have a 
user suggesting the "security vulnerability" bell on this one, and to be honest 
I don't even know what any library would do to "prevent" this.

Basically, the datetime() object limits based on a numerical year of MINYEAR, 
rather than limiting based on an actual logical date.

So I can create an "impossible" date as follows:


d = datetime.strptime("Mon Jan  1 00:00:00 0001 +01:00", "%c %z")

or like this:

d = datetime(year=1, month=1, day=1, tzinfo=timezone(timedelta(hours=1)))

andyou can see where this is going - it can't be converted to a timezone 
that pushes the year to zero:

>>> from datetime import datetime, timezone, timedelta
>>> d = datetime(year=1, month=1, day=1, tzinfo=timezone(timedelta(hours=1)))
>>> d.astimezone(timezone.utc)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: date value out of range

this because, after all, astimezone() is just subraction or addition and if it 
overflows past the artificial boundary, well you're out of luck.

Why's this a security problem?   ish?because PostgreSQL has a data type 
"TIMESTAMP WITH TIMEZONE" and if you take said date and INSERT it into your 
database, then SELECT it back using any Python DBAPI that returns datetime() 
objects like psycopg2, if your server is in a timezone with zero or negative 
offset compared to the given date, you get an error.  So the mischievous user 
can create that datetime for some reason and now they've broken your website 
which can't SELECT that table anymore without crashing.

So, suppose you maintain the database library that helps people send data in 
and out of psycopg2.We have, the end user's application, we have the 
database abstraction library, we have the psycopg2 driver, we have Python's 
datetime() object with MIN_YEAR, and finally we have PostgreSQL with the 
TIMEZONE WITH TIMESTAMP datatype that I've never liked.

Of those five roles, whose bug is this?I'd like to say it's the end user 
for letting untrusted input that can put unusual timezones and timestamps in 
their system.   But at the same time it's a little weird Python is letting me 
create this date that lacks the ability to convert into UTC. thanks for 
reading!

--
components: Library (Lib)
messages: 388585
nosy: zzzeek
priority: normal
severity: normal
status: open
title: we can create valid datetime objects that become invalid if the timezone 
is changed
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com