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.
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