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

More refactor around extended time #978

Merged
merged 5 commits into from
Oct 23, 2024
Merged

More refactor around extended time #978

merged 5 commits into from
Oct 23, 2024

Conversation

Tang8330
Copy link
Contributor

@Tang8330 Tang8330 commented Oct 23, 2024

  1. Specifying layout for Date
  2. Updating all the places we used to call ExtendedTime.String() to go through GetTime()

@@ -10,16 +10,20 @@ import (

type Date struct{}

func (Date) ToKindDetails() typing.KindDetails {
return typing.NewExtendedTimeDetails(typing.ETime, ext.DateKindType, "")
func (Date) layout() string {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifying a layout

@Tang8330 Tang8330 marked this pull request as ready for review October 23, 2024 17:28
@Tang8330 Tang8330 requested a review from a team as a code owner October 23, 2024 17:28
@Tang8330 Tang8330 changed the title Refactoring Extended Time to use string less More refactor around extended time Oct 23, 2024
@@ -284,14 +284,14 @@ func TestField_ParseValue(t *testing.T) {
field := Field{Type: Int64, DebeziumType: MicroTime}
value, err := field.ParseValue(int64(54720000000))
assert.NoError(t, err)
assert.Equal(t, "15:12:00.000000", value.(*ext.ExtendedTime).String(""))
assert.Equal(t, "15:12:00.000000", value.(*ext.ExtendedTime).GetTime().Format("15:04:05.000000"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we use MicroTime{}.layout() here instead of hardcoding the layout?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'll run into a cyclical dependency import since it's not in the same package :(

@Tang8330 Tang8330 merged commit 97f05e9 into master Oct 23, 2024
3 checks passed
@Tang8330 Tang8330 deleted the use-string-less branch October 23, 2024 18:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants