Keep time location in zap.Time

[hnakamur]

The zap.Time() did convert the time value to integer using time.UnixNano().

zap/field.go

Line 178 in 7641ffe

return zapcore.Field{Key: key, Type: zapcore.TimeType, Integer: val.UnixNano()}

This means we lost the location information.
So EncodeEntry() for JSONEncoder and ISO8601TimeEncoder returned the time string with the local timezone, not the original location specified in the time value passed to zap.Time().

I add a test case to reproduce this problem at zapcore/json_encoder_entry_test.go.
Notice this test case fails only for environments whose timezone is not UTC.

This pull request fixes this problem with setting the time value to the Interface field of Field instead of Integer field.

To maintain backward compatibility, I modified the TimeType case in func (f Field) AddTo(enc ObjectEncoder) to use Interface field when it is set (not nil) and use Integer field otherwise.

Could you review this pull request?
Thanks!

[CLAassistant]

All committers have signed the CLA.

[akshayjshah]

Interesting - I hadn't considered the need to preserve time zones. This PR can't be merged as-is, since it introduces a performance regression in zap.Time.

However, we may be able to solve this problem another way. Can you clarify for me exactly what you need here? Do you need to preserve the original time zone, or do you need to encode all times in a single (non-system) time zone?

[akshayjshah]

Good catch... :(

Thanks for adding the license.

[akshayjshah]

Unfortunately, this makes every call to Time allocate.

[hnakamur]

I made another try: 384c2f1
This time, we don't have extra allocate.

[hnakamur]

Thanks for your comments.
I need to preserve the original time zone.
I think times in UTC should be printed with timezone 'Z' and times in JST+9 should be printed with timezone '+0900'.
The current zap prints timezone '+0900' for times in UTC too.

[akshayjshah]

Looks great - thanks for the contribution!

[hnakamur]

Thanks for merging!