Bug: Issue with API field data types (specificially dates)

Version: 3.2.0 Running in linux server docker container

– Apologies in advance if this is an oversight on my part. I have spent hours looking for similar issues and verifying on my end.

The main issue is that all Date Time fields are not returning in a standard ISO 8601-1:2019 format. the API swagger shows that it should, but the actual call is not.

Attaching the screenshot from the swagger ui page for clarity:

example 1: notice how the “example” shows the correct date format. I checked the UI and nothing appears configured incorrectly.

Further, you can see the identifier fields that are supposed to be numerical being returned as strings. Obviously these issues may seem minor but they make consuming the API a non-starter (without a bunch of custom deserializers).

example 2:

Happy to provide any further detail as necessary. Should be fairly easy to recreate I think.

[berrnd]

Changing something like that would be a breaking API change affecting (probably) anyone currently using the API. I try to avoid those changes where possible, also when it’s against some “standard”. I already know that grocy is just ugly in every kind regarding that manner, just because I hear it kind of every week since this projects got a little more attention.

If that “problem” is solvable by doing nothing for 3 of the 5 examples above and for the other 2 the solution is providing the format, I still don’t get the real “problem”.

Seems that there are a couple of more lines needed for System.Json.Net, sorry, this seems then to be my fault I guess, as everything regarding that - quick and dirty example which works (don’t doing that much .Net myself and it kind of took me 10 minutes to get it working):

using System;
using System.Text.Json;
using System.Text.Json.Serialization;

namespace ConsoleApp1
{
	class Program
	{
		class XDateTimeConverter : JsonConverter<DateTime>
		{
			public override DateTime Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
			{
				return DateTime.Parse(reader.GetString());
			}

			public override void Write(Utf8JsonWriter writer, DateTime date, JsonSerializerOptions options)
			{
				writer.WriteStringValue(date.ToString("yyyy-MM-dd HH:mm:ss"));
			}
		}

		class Product
		{
			public string? Name { get; set; }
			public DateTime XDate { get; set; }
		}

		static void Main(string[] args)
		{
			string json = @"{""Name"":""Banana"",""XDate"":""2022-03-23 00:01:32""}";
			
			var options = new JsonSerializerOptions();
			options.Converters.Add(new XDateTimeConverter());

			Product p = JsonSerializer.Deserialize<Product>(json, options)!;
			Console.WriteLine(p.Name);
			Console.WriteLine(p.XDate);
		}
	}
}

[addd45]

Yeah, I get not wanting to make a breaking change, I do wonder how breaking it would be though if a client is using standard libraries to parse dates, but I digress…

FWIW I just wanted to bring up the issue before going with the workaround, but fully understanding it’s probably not feasible without some big refactoring and breaking changes.

Anyway I will use the custom converter as you demonstrated above. Really appreciate you giving that example code. Microsoft documentation as usual couldn’t be straightforward and I wasn’t in the mood to deep dive into it 😃