LabRAD Manager is finicky with python datetime objects

[pomalley]

If I try to set a registry key to datetime.datetime.now things work. If I try to set it to datetime.datetime(2015, 4, 20, 1, 1, 1) then things don't work.

Ideas?

[maffoo]

what exactly doesn't work?

[pomalley]

Right, my bad. Specifically the second case seems to put None in the registry, or at least when I pull it back I get None (and the registry editor shows a -). This could be a bug with the registry wrapper, to be fair.

[maffoo]

I think this is a manager bug. In particular, the current registry converts data to a human-readable string and stores it to disk, then parses that string representation and converts it back to labrad data when you try to get from the registry. The string formatting and parsing is buggy:

>>> import datetime
>>> x = datetime.datetime(2015, 4, 20, 1, 1, 1)
>>> import labrad
>>> cxn = labrad.connect()
>>> cxn.manager.data_to_string(x)
'04/20/2015 01:01:01.19792127609253E-7'

>>> cxn.manager.string_to_data(cxn.manager.data_to_string(x))

Note that last blank line; the manager is returning None when it fails to parse the string. This works with the new scala manager, which uses ISO standard date format:

>>> cxn.manager.data_to_string(x)
'2015-04-20T08:01:01.000Z'

>>> cxn.manager.string_to_data(cxn.manager.data_to_string(x))
datetime.datetime(2015, 4, 20, 1, 1, 1)

Two other notes: the new manager returns an error if you try to parse data from a string it doesn't understand (rather than empty data), and the new registry stores data in the same binary representation as is sent over the wire, so registry integrity will not be compromised by bugs in the stringification.

[ejeffrey]

I just checked this out in the filesystem on skynet, and it is indeed storing '04/20/2015 01:01:01.19792127609253E-7' on disk, but failing to read it back.

Playing around a bit more, I am finding other bugs where it returns the wrong data. For instance:

x = datetime.datetime(2015, 4, 20, 1, 1,2) cxn.manager.data_to_string(x) '04/20/2015 01:01:02.999999824911356'

i.e., one second off.

On Mon, Apr 20, 2015 at 2:59 PM, Matthew Neeley notifications@github.com wrote:

I think this is a manager bug. In particular, the current registry converts data to a human-readable string and stores it to disk, then parses that string representation and converts it back to labrad data when you try to get from the registry. The string formatting and parsing is buggy:

import datetime>>> x = datetime.datetime(2015, 4, 20, 1, 1, 1)>>> import labrad>>> cxn = labrad.connect()>>> cxn.manager.data_to_string(x)'04/20/2015 01:01:01.19792127609253E-7' cxn.manager.string_to_data(cxn.manager.data_to_string(x))

Note that last blank line; the manager is returning None when it fails to parse the string. This works with the new scala manager, which uses ISO standard date format:

cxn.manager.data_to_string(x)'2015-04-20T08:01:01.000Z' cxn.manager.string_to_data(cxn.manager.data_to_string(x)) datetime.datetime(2015, 4, 20, 1, 1, 1)

Two other notes: the new manager returns an error if you try to parse data from a string it doesn't understand (rather than empty data), and the new registry stores data in the same binary representation as is sent over the wire, so registry integrity will not be compromised by bugs in the stringification.

— Reply to this email directly or view it on GitHub https://github.com/martinisgroup/pylabrad/issues/87#issuecomment-94579365 .

[pomalley]

OK, well, that's discouraging (not that a second going to matter, but still). It would be nice to get this fixed, but I'm not sure how that's going to happen if the manager is the culprit. Other than for the scala manager to get going...