srishanbhattarai / nepcal Goto Github PK

This issue was generated by todo based on a TODO comment in d8ec188 when #16 was merged. cc @srishanbhattarai.

Collection of my thoughts around date normalization in Nepcal.

#79 reported a bug where a B.S. date that overflowed into the next month would not be rejected by Nepcal.

The provided example was 12-31-2076 which is to be considered invalid because the month of Chaitra does not contain 31 days, it only contains 30. The current behavior (although implicit) was that this date would overflow over to 01-01-2077, and any B.S. to A.D. conversions would use this value.

From the user's perspective:
a) 01-01-2077 converts into April 13, 2020 Monday (so far so good!)
b) 12-31-2076 ALSO converts into April 13, 2020 Monday because of the overflow.

This silent overflow behavior is also exhibited by Go's own time package - if you call time.Date with the date February 30 it will overflow to April, which is why I recall keeping the current behavior the way it is. We will use the same taxonomy for this behavior and call it normalization.

#80 proposes to change the current behavior by explicitly rejecting dates that would have normalized. My thoughts at this moment are the following:

a) Error-ing out seems the right decision here, instead of silent behavior the user may be unaware of. However, I don't want Hyrum's law to bite me if I change this, so this release should be a version bump at the minimum.

b) For B.S. dates, we typically work with raw "dd, mm, yy" values so it's easy to check for normalization. What do we do for A.D. dates i.e. the FromGregorian functions which directly take in a time.Time. Should nepcal also have guard rails against allowing normalization of A.D. dates?
To be clear, this means breaking the FromGregorian API to ingest a "dd, mm, yy" triple similar to B.S. dates, explicity check if this date will normalize, and reject it. Again, Hyrum's law, and therefore version bump?

The std lib tabwriter doesn't handle ANSI escapes, so we've to resort to non-optimal output. The tabwriter algorithm seems simple enough to recreate.

Hi, I'm interested in solving this issue. I've already implemented this in the current codebase, but I'll wait to create the PR until the restructuring in #35 is completed. Thanks.

There have been several instances in which I simply forgot to update the version number in code for the CLI

I believe the way to do this should be an ldflags build time variable.

The Goreleaser build page has more information. Example:

    ldflags:
     - -s -w -X main.build={{.Version}}
     - ./usemsan=-msan

The {{.Version}} template seems to automatically do the right thing as described here which uses the current tag as the version number.

This issue was generated by todo based on a TODO comment in 33e3313 when #14 was merged. cc @srishanbhattarai.

Just like cal we should highlight the current date when displaying the calendar.

The initial design for the package structure was simple:

1. dateconv package would provide functions to convert to and from Nepali dates
2. main package would be the executable package that would render the calendar

While it has worked fine 'til now, as more and more "non-conversion" functionality gets added, the dateconv package doesn't make sense because the package does much more than just convert dates.

12-31-2076 BS is a invalid date (it only has 30 days), but it converts to 13-April-2020
But 13-April-2020 is actually 01-01-2077

Currently, the CLI does the manual work of creating the calendar, but it can be done by the nepcal package for any date. An interface like the following could be exposed:

type Calendar struct {
  // Use a sentinel to denote empty days
  weeks [][7]int

  // could contain some information derived from the time. 
  // expose via methods
 StartWeekday Weekday
 NumDaysInMonth int
}

func (t Time) Calendar() Calendar {}

• Installation instructions
• Usage instructions
• License information

The dateconv package features an exported Epoch struct. This is used to represent a point in time. This should be removed so we only work with stdlib types.

Basically remove this to return an error and make consequential changes.

- func ToBS(adDate time.Time) BSDate {
+ func ToBS(adDate time.Time) (BSDate, error) {
        if !adDate.After(adLBound) {
-		panic("Can only work with dates after 1943 April 14.")
+		return sentinelBsDateValue, ErrDateOutOfBounds
        }
}

This needs to happen for:

1. the Stringer interface on nepcal.Weekday
2. the CLI calendar needs to use abbreviated versions, using a new method (e.g. Abbr())
3. Change README calendars as well

For easy copy pasta:

Sunday आइतवार
Monda सोमवार
Tuesday मङ्गलवार
Wednesday बुधवार
Thursday बिहिवार
Friday शुक्रवार
Saturday शनिवार

I was reading through the code and saw this piece of code.

The question that popped in my head right away is how can we possibly get the right Bikram Sambat dates if we use the inbuilt time.Date function which possibly follows the Gregorian calendar.

The Gregorian calendar never exceeds 31 days. However, the Bikram Sambat calendar does.

I quickly checked the Nepali calendar and found June 15, 2019 to be जेठ 32, 2076. I tried converting this date and here are the results.

Wrong Results: ❎

nepcal conv adtobs 06-15-2019
असार 3, 2076 शनिबार

nepcal conv adtobs 06-13-2019
असार 1, 2076 बिहिबार

Right Results: ✅

nepcal conv adtobs 06-18-2019
असार 3, 2076 मंगलबार

nepcal conv adtobs 06-17-2019
असार 2, 2076 सोमबार

Let's take June 15, 2019 as an example. Supposedly, the conversion is right and we get year, month, days to be 2076, 02, 32 which translates to जेठ 32, 2076.

Now when we pass this result to toTime it will try to convert these dates to Gregorian calendar. If you take a look at the 2076 Gregorian calendar, the month of February (02) has only 29 days. Amazingly, what time.Date tries to do here is append the excess of 3 days and add it to the next month. This results in the output of 2076, 03, 03 which is असार 3, 2076.

There might be plethora of dates that don't convert well. 😛

The output of the command cal is something like this:

      May 2018
Su Mo Tu We Th Fr Sa
       1  2  3  4  5
 6  7  8  9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

The eventual goal of nepcal is to attain sensible parity with cal. It starts with printing the formatted calendar output as the default behavior.

Challenges:

• Figuring out the day of the start of the month. This is easy for A.D. systems because of deterministic month lengths (barring leap years), but more involved for B.S. systems. We can get the current A.D. date and day, translate that into B.S. and calculate the offset from the start date of the month to get the start day.
• cal block highlights(?) today's date, but I'd prefer it be cyan colored to be more subtle.

Probably is an issue with urfave/cli. Cannot be sure as I have not taken a deeper look.

urfave/cli#546

Output right now.

$ nepcal -v

flag provided but not defined: -v
Usage of nepcal:

$ nepcal -h

Usage of nepcal:

Hi. this seems a great utility for BS calendar.
If it's not asking too much, if we could have a pypi version of this application with basic datetime operations, it would be great for python developers.

• Homebrew, MacOS (9df5ebe)
• apt, Ubuntu
• AUR, Arch Linux
• Chocolatey, Windows #

nepcal by default should convert calendar dates into nepali numerals.

Can have a flag to change it back to english numerals (whatever it is called).

At one point (d8ec188) in August of 2018, an experimental GRPC implementation was briefly considered.
Providing some form of API access has always been on my mind. The only limiting factor here was that the package wasn't really structured to be able to do this (and I have stayed busy). With #48 having landed in v1.0.0 this avenue opens up.

There are several ways this could be done. This issue is to serve as a distillation of the information/decisions taken on that front (it's mostly for me by me).

Just seeing this for the first time today.

Warning: Calling bottle :unneeded is deprecated! There is no replacement.
Please report this issue to the srishanbhattarai/nepcal tap (not Homebrew/brew or Homebrew/core):
  /usr/local/Homebrew/Library/Taps/srishanbhattarai/homebrew-nepcal/Formula/nepcal.rb:6