Issue on CentOS 7 about syncthingmanager HOT 8 CLOSED

I get syncthing from https://syncthing.net/. I simply download what they offer on the front page there. I don't compile it myself.

Now I have had a look at another CentOS machine and I get 9 digits indeed!
"startTime": "2017-05-16T15:56:02.148356688+01:00"

On a Debian Jessie machine, I also get 9 digits:
"startTime": "2017-05-16T05:03:00.568656459-04:00"

On a Mac, also 9 digits:
"startTime": "2017-05-28T08:19:39.053928488+01:00",

So, after closer inspection, the 3 digits are showing up on only one machine, it seems. The only thing this machine has different as far as I can tell is that it has an AMD CPU whereas the others run Intel...

Anyway, with a combination of curl'ing the REST API and hacking python-syncthing, I will manage to do what I need. What we have established is that your program is functioning correctly and then I guess this bug report can be closed.

Thanks a lot.

from syncthingmanager.

Hi Lyderic
I haven't been able to reproduce the issue at this point. For comparison, could you do the following?

[sam@sam-pc ~]$ python3
Python 3.6.0 (default, Jan 16 2017, 12:12:55) 
[GCC 6.3.1 20170109] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import syncthing
>>> s = syncthing.Syncthing('YOUR_API_KEY', port=YOUR_GUI_PORT)
>>> s.system.get('status')['startTime']
'2017-04-18T14:08:41.03238611-07:00'

Thanks

from syncthingmanager.

Hi Samuel,

Many thanks for looking at this.

Here you are:

[lyderic@cube ~]$ python3
Python 3.4.5 (default, Nov  9 2016, 16:24:59) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-11)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import syncthing
>>> s = syncthing.Syncthing('JFUSxxxxxxxxxx', port=8384)
>>> s.system.get('status')['startTime']
'2017-04-19T10:04:13.698+01:00'

from syncthingmanager.

Thanks for the info, I've been too busy to look at it. Looks like your Syncthing is giving the startTime string in a format that the Python datetime library can't handle. Specifically, it may be giving the microsecond without zero-padding (698 in the above output should probably be 00000698 or 69800000).

My suggestion for now would be to install the latest version of Syncthing and try it again. If that doesn't work, there may be an issue somewhere. FWIW, all my Syncthing instances appear to be giving startTime in the expected format.

from syncthingmanager.

@lyderic Did you start syncthing? I know that this is really basic, but I was getting errors as well, and I didn't really think about it since I always enable Syncthing to start on boot on my other machines.

from syncthingmanager.

@mhaffner Always worth checking, but I doubt that is the issue here. If the API wasn't up then we wouldn't be getting startTime at all.

from syncthingmanager.

Thanks for your answers / suggestions.

1. @mhaffner I am sure I am running syncthing, as for one, the GUI is available.

2. @classicsc I am running the latest syncthing 0.14.28 and I still have the issue :-(

If I get the startTime directly from the 'rest/system/status' REST endpoint (with curl), I get:
"startTime": "2017-05-16T20:05:16.731+01:00"

Please note that only 3 digits are provided after the decimal point. This is specific to RedHat (CentOS) Linux. On Ubuntu, I get 9 digits:
"startTime": "2017-05-24T14:20:20.969692135+01:00",

You, it seems, get 8 digits. From what you provide above, on April 19:
'2017-04-18T14:08:41.03238611-07:00'

Can it be that your program always expects 8 digits to parse? If yes, then a fix could be to cut the first 3 digits provided and then only always parse 3 digits...

Many thanks for your time.
L.

from syncthingmanager.

Alright, thanks for the confirmation. I still can't reproduce the issue on CentOS (same version and platform), which makes it difficult to figure out exactly what is happening.

One fix would involve the python-syncthing package, specifically reworking the parse_datetime method. Similar to what you described, we could use a regular expression to parse the timestamp for its components, which is more flexible than the current method of taking substrings. For example:

syncthing_datetime_re = re.compile(r'(?P<year>\d{4})-(?P<month>\d\d)-(?P<day>\d\d)'
             r'T(?P<hour>\d\d):(?P<minute>\d\d):(?P<second>\d\d)(\.0*(?P<fsec>\d{1,6})\d*)?'
             r'((?P<offset_direction>\+|\-)(?P<offset_hour>\d\d):(?P<offset_minute>\d\d))?')

Where are you getting Syncthing? I use the tgz from GitHub and my own systemd units, but if you're using a package or building locally, that could help with reproducing the behaviour.

from syncthingmanager.