Right now there is no simple way to get a timezone-aware time for the current time in the current time zone [without resorting to outside libraries like pytz], I would like to propose a simple extension to datetime.now to allow returning an aware datetime object using a plain single-offset tzinfo object: datetime.now('auto') shall return a datetime using a simple offset-based timezone object. [Incidentally, I also think that utcoffset() on naive timestamps should be able to return the offset that astimezone would use to convert the time. I only discovered it didn't while writing this proposal] some simplistic possible implementations: def utcoffset_naive(dt): ut = dt.astimezone(datetime.timezone.utc).replace(tzinfo=None) return dt - ut def now_auto(): now = datetime.datetime.now() return now.replace(tzinfo=datetime.tzinfo(utcoffset_naive(now)), fold=0) A better implementation though would be to capture tm_gmtoff, and perhaps also tm_zone for tzname, from localtime() inside _fromtimestamp. This could also bypass the fold detection stage because single-offset tzinfo objects have no folds. I am specifically *not* proposing the creation of a tzinfo class representing "just use the local time as-is", because the meaning of timestamps with such a tzinfo attached might change during the lifetime of a program when system settings and/or environment variables are changed. A tzinfo class that identifies a system-specific timezone might be viable, but on some systems may require setting global state such as environment variables before each conversion. Also, such a tzinfo object could simply be passed as-is to datetime.now, whereas my proposal is to automatically select from (typically) two different fixed-offset tzinfo objects that would be used for DST and non-DST timestamps. This could be accomplished with a tzinfo class whose fromutc method always returns a datetime with a fixed-offset tzinfo attached, but I don't know if this aspect of the tzinfo API [that fromutc may return a datetime with any timezone attached, or indeed any object] is documented or stable, or what the other consequences would be [e.g. what if such a tzinfo object is attached to a datetime directly using the constructor or replace]? A magic sentinel object such as the string 'auto' allows this functionality to be limited to now (and perhaps fromtimestamp) without the unintended consequences of a 'magical' tzinfo escaping into other parts of the API.
On Sat, Jan 4, 2020, at 15:11, Random832 wrote:
...
I just discovered, in the course of trying to make a more fleshed-out implementation, that the correct way to do this is datetime.now().astimezone(None) - this isn't explained very well in the documentation. I did notice, though that a datetime created in this way does not return anything for dst(). And the part where I think naive datetimes should be able to answer utcoffset(), tzname(), and dst() using the system local time still stands. I think that calling one of these functions on a naive datetime is likely to be a mistake in any code that does so now, and that calling one of them check if it is naive seems unlikely vs just checking obj.tzinfo is None.
participants (1)
-
Random832