Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dump.Print does not print a type alias of time.Time field in a struct correctly #200

Closed
SimonBuckner opened this issue Oct 31, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@SimonBuckner
Copy link

First of all, apologies if I have missed the correct way of handling this in the documentation.

  • OS: Windows and Linux via WSL2
  • GO Version: 1.23.2
  • Pkg Version: v0.6.17

Describe the bug
I'm querying an API where most timestamps play nice and are handled by 'json.Unmarshal'. However, there is API endpoint that returns a date that matches this format '2006-01-02T15:04:05' which is not handled by default. When I implement a custom unmarshall receiver on a type alias, then dump.Print does not print the timestamp correctly.

type RestorePoint struct {
	Timestamp      RestorePointTimestamp `json:"timestamp"`
	InUse          bool                  `json:"in_use"`
	UsageInitiator string                `json:"usage_initiator"`
}
type RestorePointTimestamp time.Time

func (t *RestorePointTimestamp) UnmarshalJSON(b []byte) error {
	value := strings.Trim(string(b), `"`) //get rid of "
	if value == "" || value == "null" {
		return nil
	}

	out, err := time.Parse("2006-01-02T15:04:05", value) //parse time
	if err != nil {
		return err
	}
	*t = RestorePointTimestamp(out) //set result using the pointer
	return nil
}

When I dump out the struct using dump.Print, the timestamp is not printed as its underlying time.Time format. See below.

      axcientapi.RestorePoint {
        Timestamp: axcientapi.RestorePointTimestamp {
          wall: uint64(0),
          ext: int64(63865950120),
          loc: *time.Location<nil>,
        },
        InUse: bool(false),
        UsageInitiator: string(""), #len=0
      },

As you can see it prints wall, ext and loc instead of the underlying time.Time. Here is an example from another part of the API that does have a clean time format and prints as I would expect.

  },
  axcientapi.OrgLevelAutoverifyInfo {
    Timestamp: time.Time(2024-10-02T19:02:46Z),
    StartTimestamp: time.Time(2024-10-02T18:47:42Z),
    EndTimestamp: time.Time(2024-10-02T19:02:46Z),

  },

To Reproduce
See the code here: [https://play.golang.com/p/oCINSaKIogT]

import (
	"fmt"
	"github.com/gookit/goutil/dump"
	"time"
)

var dateValue = "2024-10-02T19:02:46"

type RestorePointTimestamp time.Time

type NormalRestore struct {
	TimeStamp time.Time
}

type CustomRestore struct {
	TimeStamp RestorePointTimestamp
}

func main() {

	fmt.Println()
	fmt.Println("Please note this is normally handles as a custom Unmarshall method for the JSON package")

	normal, _ := time.Parse("2006-01-02T15:04:05", dateValue)
	normalRestore := NormalRestore{
		TimeStamp: normal,
	}

	custom, _ := time.Parse("2006-01-02T15:04:05", dateValue)
	customRestore := CustomRestore{
		TimeStamp: RestorePointTimestamp(custom),
	}
	
	fmt.Println()
	fmt.Println("This is how I'd like to see the date to output:")
	dump.Print(normalRestore)
	fmt.Println()
		
	fmt.Println()
	fmt.Println("This is how what I actuall get:")
	dump.Print(customRestore)
}

Expected behavior

dump.Print for the custom timestamp I'd like to see this.

TimeStamp: time.Time(2024-10-02T19:02:46Z)

Additional context

@inhere inhere added the enhancement New feature or request label Nov 1, 2024
@inhere inhere closed this as completed in e959274 Nov 2, 2024
@inhere
Copy link
Member

inhere commented Nov 2, 2024

@SimonBuckner Resolved.

Now, use dump.Print(customRestore) will output:

=== RUN   TestIssues_200/custom_time
PRINT AT github.com/gookit/goutil/dump_test.TestIssues_200.func2(issues_test.go:41)
dump_test.CustomRestore {
  TimeStamp: dump_test.RestorePointTimestamp(2024-10-02T19:02:46Z),
},
--- PASS: TestIssues_200/custom_time (0.00s)

@SimonBuckner
Copy link
Author

Hi,
Thanks for the quick response. That has fixed the issue perfectly.

Thanks
Simon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants