The Github issue is this one, by the way:

Note that an alternative for debugging would be to use a
DebuggerDisplayAttribute applied on the partial class. Haven't tried this
myself, but will look into it.


On 4 November 2015 at 20:25, Jon Skeet <> wrote:

> The C# codegen only works for proto3 anyway.
> Out of your examples, I'd use Duration and Timestamp - and probably just a
> string for Guid. That's the one I'd be most convinced by though, as the
> difference in storage between the text and binary representation is so
> high. Note that this would only be for diagnostic purposes though - the
> Json formatter and parser will not use it.
> (I don't know whether any other platforms support this, mind you...)
> Jon
> On 4 Nov 2015 8:19 p.m., "Teddy" <> wrote:
>> Thanks for the info on Noda Time. I'll consider using Noda Time when we
>> move to proto 3.
>> The issue here is actually creating custom message for common types like
>> the DateTime above (which seems to be a poor example). Other common types
>> we need are guid, timespan, unix time etc. We want to have a user friendly
>> representation in debugger/logs for easier debugging/troubleshooting.
>> On Wed, Nov 4, 2015 at 12:00 PM, Jon Skeet <> wrote:
>>> Hmm... I posted a reply to this yesterday, but apparently it didn't make
>>> it through. Let's see if this one gets through to the group.
>>> I've raised an issue for it on Github, but don't have any plans to
>>> support it imminently.
>>> I would strongly urge you away from your current platform-specific
>>> DateTime representation. If you can, use the Timestamp well-known type,
>>> which has a custom Json representation. If not, consider another
>>> platform-neutral representation which is likely to be more readable in a
>>> string form anyway. (DateTime is somewhat broken as a type anyway. When
>>> Noda Time 2.0 is out, I intend to create another Nuget package to bridge
>>> that and Protobuf. The choice of nanosecond precision in Noda Time 2.0 was
>>> influenced by proto3.)
>>> Jon
>>> On 4 Nov 2015 7:51 p.m., "Teddy Zhang" <> wrote:
>>>> +Jon who seems to be the developer on this.
>>>> On Monday, November 2, 2015 at 6:18:27 PM UTC-8, Teddy Zhang wrote:
>>>>> I need to override the ToString behavior in C# to make it human
>>>>> readable.
>>>>> E.g. I defined a message type to represent DateTime in C#, and then
>>>>> write a partial class to make it be able to convert from/to DateTime.
>>>>>> message ProtoDateTime
>>>>>> {
>>>>>>      sfixed64 BinaryData = 1;
>>>>>> }
>>>>> However, the default ToString() doesn't generate human readable
>>>>> contents.
>>>>> Currently the default implantation is (codegen code):
>>>>> public override string ToString() {
>>>>> return pb::JsonFormatter.Default.Format(this);
>>>>> }
>>>>> Which will generate something like this, which is not readable.
>>>>> { "dateTime": { "binaryData": "5247507155853679530" } }
>>>>> Is there a way to override this behavior?
>>>>> If not, is there a plan to support this? Thanks.

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
To post to this group, send email to
Visit this group at
For more options, visit

Reply via email to