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

Off-by-One in lunar date calculation #83

Closed
benzammour opened this issue Aug 4, 2021 · 4 comments
Closed

Off-by-One in lunar date calculation #83

benzammour opened this issue Aug 4, 2021 · 4 comments
Labels
Bug Report a reproducible bug or regression Fixed Bug fixed

Comments

@benzammour
Copy link
Contributor

Hello,

I encountered an issue with the following code:

carbon.Parse("2021-06-14").Lunar()

carbon version: v1.4.6

golang version: go version go1.16.6 linux/amd64

I expected to get (in yyyy-mm-dd format):

2021-05-05

But I actually get:

2021-05-04

Thanks!


Additional info:
I encountered this issue when I was working on a test for a pull request.
The festival tests in calendar.lunar_test.go:52 always fail because the date is off-by-one, causing the program to find empty festivals for a correct date.
I tried fixing the issue myself but I'm simply not versed enough in Chinese dates to do so.

Here's also an example illustrating this error while using the library itself (opposed to the testing environment)

package main

import (
	"fmt"
    "github.com/golang-module/carbon"
)

func main() {
	lunarTime := carbon.Parse("2021-02-12")
	fmt.Printf("First Festival, Greogorian Date: %s\n", lunarTime)

	lunarDate := lunarTime.Lunar()
	festival := lunarDate.Festival()
	fmt.Printf("First Festival, Lunar Date: %d-%d-%d\n", lunarDate.Year(), lunarDate.Month(), lunarDate.Day())
	fmt.Printf("Festival: %s\n", festival)

	fmt.Println()

	lunarTime = carbon.Parse("2021-06-14")
	fmt.Printf("Second Festival, Greogorian Date: %s\n", lunarTime)

	lunarDate = lunarTime.Lunar()
	festival = lunarDate.Festival()
	fmt.Printf("Second Festival, Lunar Date: %d-%d-%d\n", lunarDate.Year(), lunarDate.Month(), lunarDate.Day())
	fmt.Printf("Festival: %s\n", festival)
}

Command:

$ go run main.go 

Output:

First Festival, Greogorian Date: 2021-02-12 00:00:00
First Festival, Lunar Date: 2021-1-1
Festival: 春节

Second Festival, Greogorian Date: 2021-06-14 00:00:00
Second Festival, Lunar Date: 2021-5-4
Festival: 
@gouguoyin
Copy link
Collaborator

gouguoyin commented Aug 4, 2021

What is your current time zone?you can try
carbon.Parse("2021-06-14", carbon.PRC).Lunar()

@benzammour
Copy link
Contributor Author

I'm currently in the time zone of Berlin (GMT+02:00), but using PRC, Berlin or Tokyo does not change the result [1].
The same happens if I use carbon.SetTimezone(carbon.{Berlin, Tokyo, PRC}).Parse("2021-06-14").Lunar().

However, I tried London as well, just to see if it changes anything, and here it converts it correctly [2].

[1]:

func main() {
	lunarDate := carbon.Parse("2021-06-14", carbon.{Berlin, Tokyo, PRC}).Lunar()
	festival := lunarDate.Festival()

	fmt.Printf("Lunar Date: %d-%d-%d\n", lunarDate.Year(), lunarDate.Month(), lunarDate.Day())
	fmt.Printf("Festival: %s\n", festival)
}

Output:

Lunar Date: 2021-5-4
Festival: 

[2]:

func main() {
	lunarDate := carbon.Parse("2021-06-14", carbon.London).Lunar()
	festival := lunarDate.Festival()

	fmt.Printf("Lunar Date: %d-%d-%d\n", lunarDate.Year(), lunarDate.Month(), lunarDate.Day())
	fmt.Printf("Festival: %s\n", festival)
}

Output:

Lunar Date: 2021-5-5
Festival: 端午节

@gouguoyin
Copy link
Collaborator

Thank you very much.I found the reason for the bug because CreateFromDateTime() method on line 62 of calendar.lunar.go file didn't set PRC time zone.I will fix this bug in the next version.

image

@gouguoyin gouguoyin added the Bug Report a reproducible bug or regression label Aug 5, 2021
@gouguoyin
Copy link
Collaborator

Fixed in v1.5.0

@gouguoyin gouguoyin added the Fixed Bug fixed label Aug 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Report a reproducible bug or regression Fixed Bug fixed
Projects
None yet
Development

No branches or pull requests

2 participants