Friday, December 15, 2017

AmbiguousTimeError

Yesterday Tonis and I had a surprise during an otherwise routine upgrade on Jane. We called it #2204.

Today we found out how to reproduce the problem and eliminate its cause. Thanks to Ilian Iliev for publishing his blog post Django, pytz, NonExistentTimeError and AmbiguousTimeError.

When somebody living in Brussels tells you “it was at on 2017-10-29 at 01:16:06”, then you don’t know whether they mean summer or winter time. Because their clock showed that time exactly twice during that night. The timestamp “2017-10-29 01:16:06” is ambigous.

The reason for #2204 was that pm dump2py used the site’s default TIME_ZONE setting when writing the naive values of DateTimeFields in the generated applabel_modelname.py files. When trying to load a dump which contains such a timstamp, Lino would cause an AmbiguousTimeError.

So pm dump2py must make sure to express the naive time literals in a timezone which doesn’t have such ambigous hours. UTC for example.

I extended The dumps demo project so that it now verifies whether #2204 is fixed. En passant this page now also demonstrates three methods of writing demo multilingual data for babel fields.

Authenticate using Facebook

I added Facebook as a third authentication backend to the lino_book.projects.team demo project and updated the Social Authentication page.

Before doing this, I reappeared on Facebook after two years of absence (not two and a half, as I first thought when writing this). Oh no, it’s not because I have become their friend. It’s rather because having no Facebook account while continuing to have a Google account is even worse than having a FB account as well. Both Facebook and Google are huge powerful imperia, and every user is another buttress of their power. That’s a big problem because organizations of that size should be democratic and open instead of hierarchic and proprietary. But it’s also clear that I won’t save the world by keeping out of them…