ISO 8601 date format

[chorsley]

I'm using python-whois (a much needed library) with Celery. Celery commonly uses the standard json library, which doesn't easily handle datetime objects.

Would it be possible to add a new argument to get_whois allowing for ISO 8601 output? My naive test was basically replacing parse.py:413 and 417 with:

parsed_dates.append(datetime.datetime(year, month, day, hour, minute, second).isoformat()

Is that something you think would be possible / advisable? It would always be possible to convert any dates externally, but it would certainly be very convenient.

[joepie91]

I've had a quick look at the specifics of the JSON encoding functionality in Python's standard library, and it appears to support custom serializers through the default= parameter (in dump/dumps calls).

If Celery handles JSON encoding on your behalf (I should say that I'm not at all familiar with Celery usage), then I would expect it to have some way of defining custom serializers, much like would be the case with default= if you used the standard library encoder directly. If it does not have this functionality (yet), I feel like a cleaner solution might be to request for generic custom serializer functionality to be added to Celery - after all, there'd likely be other types of objects that might need conversion in other setups.

Could you have a look into whether this functionality already exists, or whether it would be possible to implement that into Celery itself? If that's really not an option, I can have a go at adding it to python-whois, but where possible I'd really prefer to avoid having specific encodings in the python-whois code, as this is more a transport concern than a parsing concern.

[chorsley]

Thanks for the quick reply. You can certainly set custom serializers in Celery with some effort, but I tend to generally err in favour of simplicity and predictability, and stick with the straight-up JSON serializer.

In the meantime, I had ended up putting together a simple conversion function which does the trick after receiving the whois dict back. It would probably be handy to others to streamline this step, but it's likely not worth it if this deviates from the library's goal.

[joepie91]

With "custom serializers" I was more refering to custom functionality using the default= parameter of the standard-library JSON serializer. You'd simply be specifying a custom function for otherwise unhandled types; otherwise, you're still using the standard JSON serializer.

Would you perhaps consider posting the conversion function you wrote in this issue thread? If somebody else were to run across the same requirement, it might be useful to them :)

I'll also think a bit more about whether it's feasible/desirable to have a more generic function in place for dealing with non-primitive types (without committing to a specific encoding or set of encodings).