srishanbhattarai / nepcal Goto Github PK
View Code? Open in Web Editor NEWCross-platform utilities for Nepali dates
License: MIT License
Cross-platform utilities for Nepali dates
License: MIT License
Probably is an issue with urfave/cli
. Cannot be sure as I have not taken a deeper look.
Output right now.
$ nepcal -v
flag provided but not defined: -v
Usage of nepcal:
$ nepcal -h
Usage of nepcal:
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
The initial design for the package structure was simple:
dateconv
package would provide functions to convert to and from Nepali datesmain
package would be the executable package that would render the calendarWhile 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.
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).
Lines 13 to 18 in 33e3313
TODO
comment in 33e3313 when #14 was merged. cc @srishanbhattarai.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. 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.
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:
cal
block highlights(?) today's date, but I'd prefer it be cyan colored to be more subtle.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
There have been several instances in which I simply forgot to update the version number in code for the CLI
Line 14 in 2000701
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.
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
}
}
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.
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?
This needs to happen for:
Stringer
interface on nepcal.Weekday
Abbr()
)For easy copy pasta:
Sunday आइतवार
Monda सोमवार
Tuesday मङ्गलवार
Wednesday बुधवार
Thursday बिहिवार
Friday शुक्रवार
Saturday शनिवार
Lines 23 to 28 in d8ec188
TODO
comment in d8ec188 when #16 was merged. cc @srishanbhattarai.I was reading through the code and saw this piece of code.
Line 37 in 065a8fb
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. 😛
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.
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).
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 {}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.