It appears when I use CONFD_SET_DATETIME or CONFD_SET_TAG_DATETIME on linux powerpc and include precision upto microsecond, the SET is successful but you see the bug e.g when a notification with that timestamp is getting generated.
My devel.log output:
<ERR> 18-Aug-2016::22:40:47.485 gemini confd[931]: devel-c Failed to send notification for stream ggios-notification-stream: /noticeConnectionState/notifyTime: {19,{2016,8,18,22,40,47,470922,0,0}}: {2016,8,18,22,40,47,470922,0,0} is not a valid value.
Interestingly, all is fine on linux powerpc if I only do time precision upto the seconds.
Also microseconds are NOT a problem for confd on linux i686!
Do you know if this is a known bug on linux powerpc platform - I’m using confd-basic 5.4.
I can’t find anything in the ticket system, I don’t think it’s a known issue on PPC.
Unfortunately I don’t have access to PPC hardware and can’t test myself.
Could you look at this routine from examples netconf_notifications file = notifier_builtin_replay_store.c
Q: Why is the timezone value set to 0 before setting the hour and min in the confd_datetime struct? Any special reason ! This maybe giving me grief with bad value error as in my own code I’m setting hour and min before setting the timezone!
Should I set hour and min after setting timezone in confd_datetime like this example is doing?