2) This could be consider as a bug or not, depend on your need.
If you have a date field on the database server with value 5/28/18 (dd/MM/yy format), in user device, this value could be remain the same or change into 5/29/18 or others values depends on timezone in that device. If you want this behavior, than it is OK, but if you want the real date value on the server, you need another steps to ensure that date value on the device and server is always the same no matter what timezone is for that device.
1) It makes sense to raise an error in that case. The only other option is to return 0 which can cause very bad things.
You can skip nulls in your query or convert it to a different value.
2) The ticks value is correct. When you call DateTime.Date it applies the device time zone. There are ways to convert the ticks value to string with a different time zone.
1. For now, i can, I can avoid returning null value from date type, so I guess, this isn't a problem.
2. If date converted to string, this could be the problem. I prefer, jRDC2 return date value as it was recorded on database server and not converted to device's time zone. Hope you considered this if there is an update to jRDC2.
2. If date converted to string, this could be the problem. I prefer, jRDC2 return date value as it was recorded on database server and not converted to device's time zone. Hope you considered this if there is an update to jRDC2.
If the date is stored as string then it will return as a string value.
If it is stored in a date / time type then it will return as ticks value. This is better. It returns the exact value that you need. Start a new thread in the questions forum and I'll explain.