Hacker News new | ask | show | jobs
by Walkman 3593 days ago
> I see what you mean but as soon as you deal with timezone-aware datetimes you don't really have a choice, if an hour has been skipped, it simply doesn't exist.

So somebody clearly made a mistake (either the user or the programmer not checking the input) which you can't automagically fix. Well, at least, it's a terrible idea.

I understand the intent of helping them, but you make more harm this way.

It's also against the ZEN of Python.
2 comments
lukasgraf 3593 days ago
I tend to agree.

Obviously automatic normalisation is the correct thing to do when doing arithmetic that crosses DST-rollover boundaries (this is what the Python stdlib gets wrong), but I don't think it should be done (by default) upon creation with a location-based TZ specification:

pendulum.create(2016, 10, 30, 2, 30, 00, 0, 'Europe/Paris') is ambiguous, and pendulum.create(2016, 3, 27, 2, 30, 00, 0, 'Europe/Paris') is non-existent. pytz raises AmbiguousTimeError or NonExistentTimeError respectively in cases where you try to construct local times like that and specifiy is_dst=None: http://pytz.sourceforge.net/#problems-with-localtime

With pendulum I don't see a possibility to enforce a "strict mode" that turns of those automatic assumptions.

link
sdispater 3593 days ago
I am not too kind on raising an error by default (which pytz does not do by default either but rather return the pre-DST transition time).

I think the best thing to do here is keep the current behavior (post-DST) but with an option to choose what you want exactly (post-DST, pre-DST)

link
nzjrs 3593 days ago
If the author is still reading this, I agree.
link
tedmiston 3593 days ago
A cursory glance at Django's timezone docs says pytz (which is optional but recommended) raises an exception when a time doesn't exist due to DST.

> Unfortunately, during DST transitions, some datetimes don’t exist or are ambiguous. In such situations, pytz raises an exception. Other tzinfo implementations, such as the local time zone used as a fallback when pytz isn’t installed, may raise an exception or return inaccurate results. That’s why you should always create aware datetime objects when time zone support is enabled.

https://docs.djangoproject.com/en/1.10/topics/i18n/timezones...

link