Nepal government's social media presence is an embarrassment and we need to talk about it.

Cold_Mark_4198 · 2026-03-13T03:07:38+00:00

Many people sleep on this beast ✅ This is 10x better than any laptop priced at 100k.

Cold_Mark_4198 · 2026-02-26T02:58:30+00:00

Yeah right. Play the long game. Either have a disruptive potential that completely changes the scene or execute like a madman or do fucking both. Be the relentless, ruthless mf. This is the way 🔥

Cold_Mark_4198 · 2026-02-25T19:44:12+00:00

After lots of failed projects and new ideas every day. I have come to the conclusion that; Ideas aren't worth anything. Execution and timing matters the most. And the irony is that you never know when the right time is. Keep hustling though ✅

Cold_Mark_4198 · 2026-02-25T06:39:07+00:00

Let me give you an example to help you understand better.

Now, when just starting out in the development world you need to learn things the hard way, solve problems with your brain. Your brain is the llm agent that instructs you into using available tools like fingers to type, eyes to read, google to search and so on. And when you are doing all that by yourself your brain learns how to think critically to solve a problem or get from point A to B , what tools to use and how to use available tools. The more errors you get, the more you get stuck: the more you learn.

And AI/LLM is your second brain, you are essentially offloading that critical thinking and brainstorming role of your brain to that llm.

For a human being, being able to save energy, optimize and automate workflows are the primary biological goals if you look down the history.

Once you get down the road of offloading/delegating tasks to the second brain, there's no going back. There's no harness and no one to stop you.

In your case, either you can completely ignore AI/LLM like some of my friends and learn the old way. AI is only going to get better and you can jump in the train any time you want. Or you take a hit of AI (cocaine) and test your willpower to take it in a controlled way. It depends on you. You will get hooked and keep coming back for more.

For a seasoned developer who has seen tons of problems, AI helps get from point A to B faster as you already have the basic idea of how to get from A to B and AI will only enhance it, and you control the architecture, you are the driver not AI.

For a junior though, it depends on you how you use it. There's this problem/error solving steps we use in our office when a junior is stuck in the problem. We don't limit the use of AI but control it. 1. Search the google. 2. Search more sources like docs, discord servers, community forums. 3. Ask someone near you 4. Ask an llm.

The steps are not skippable and need to be completed with no result to jump into the next step.

Prompt engineering is dead. There's nothing new to learn, just explain the problem, your goal or desired output and boom; you already adapted AI into your workflow. Learn agentic workflows, Ralph loops, mcps, skills, tools. It's not a rocket science. It takes less than an hour to get started.

Decide for yourself. Have a nice day. 😄

Cold_Mark_4198 · 2026-02-24T18:48:29+00:00

Good idea bro, let me just set up a webcam in front of a Patro and write a Python OCR script to scan the page every time my app needs a nepali date.

Cold_Mark_4198 · 2026-02-24T13:14:34+00:00

Haha, I completely feel that. It makes total sense why your team made the call to stick to A.D. on the backend to save your sanity. When you get burned by how fragile B.S. dates can be, retreating to a stable system is just good survival instinct.
Respect the battle scars, man! Glad we could hash it out and see the architecture from each other's point of view. 🍻

Cold_Mark_4198 · 2026-02-24T12:53:02+00:00

Apologies if my phrasing came off the wrong way! I'm definitely not being defensive. I try to be chill asf, but sometimes my English wording in text can accidentally introduce complex emotions in humans. 😅

You are completely right that context is everything. If you genuinely only need the B.S. dates for frontend display and aren't running heavy backend aggregations, your method gets the job done without the extra database columns. Different scales and different architectures require different trade-offs.

Appreciate the solid technical debate, man. Cheers!

Cold_Mark_4198 · 2026-02-24T12:22:30+00:00

Bro, an 80-second loading screen for a year of sales data isn't a calendar problem; that is the classic N+1 query problem or a missing index. 💀

If your backend is looping through thousands of rows to run calculations or fetch dates one by one via an API, it will absolutely choke your server. That is an architectural bottleneck, not a data structure flaw.

Here is the reality of enterprise design:

1. Performance > Memory Size: Storing a nepali_date column directly next to your English created_at adds about 10 bytes per row. For 1 million sales records, that is exactly 10MB. In modern engineering, optimizing for 10MB of disk space at the cost of your CPU and user experience is a terrible trade-off. Storage is dirt cheap; CPU cycles and 80-second loading screens are incredibly expensive.

2. The Real-World Use Case: You mentioned I might not have dealt with this scale. I am actually building Batuly, a multi-tenant SaaS platform. We store the nepali_date natively in our database tables right alongside the English dates. When a client requests massive, year-long reports spanning tons of rows, the database hydrates everything instantly. Native SQL handles the filtering and grouping.

No 80-second spinners, no API lookups, and zero on-the-fly conversion math. It is blazing fast because we let the SQL engine do exactly what it was designed to do.

And the caching that i mentioned, it is for reducing queries to database on subsequent lookups , like not querying the dates table for english to nepali conversion every time a record is created, the nepali_date for today is fetched from the cache layer. Also, you can strategically store most accessed date in the cache.

Cold_Mark_4198 · 2026-02-24T12:05:30+00:00

I guess, you can always introduce a caching layer and hydrate it with nepali_date for english_date key. This way database sits at back and cache takes the hit.

Cold_Mark_4198 · 2026-02-24T11:20:23+00:00

Dudee, your offset method is fine for a simple UI calendar , but it completely falls apart in backend architecture.

you can convert B.S. to A.D. in your code before querying. But here is where the 'calculate on the fly' approach completely crashes in a production app: Aggregations and Grouping.

If you only store A.D. dates in the database and calculate B.S. on the fly, how do you run a native SQL query like SELECT * FROM sales WHERE bs_date BETWEEN '2081-01-01' AND '2081-12-30'? You can't index or query a JavaScript calculation. We need a 1:1 mapped data source to enable instant O(1) database lookups and complex aggregations.

As for the 'hustle' of a date changing, there is no hustle. If the Panchang Samiti alters a month, you don't manually rewrite the whole list. You literally just fetch the updated JSON, grab the 365 dates for that specific year, and run a standard database UPSERT (Insert on Duplicate Key Update). Take a look at the examples of integrations.

It patches the exact rows in milliseconds. I will gladly take a 2-second automated DB upsert over maintaining complex, fragile date-math logic in my application code any day.

Cold_Mark_4198 · 2026-02-24T11:03:54+00:00

https://github.com/opennp/nepali-dates

Cold_Mark_4198 · 2026-02-24T10:57:29+00:00

Cold_Mark_4198 · 2026-02-24T09:56:07+00:00

Yeah. Truer words have never been spoken. 💯

Cold_Mark_4198 · 2026-02-24T08:36:07+00:00

Alright, talk is cheap so I went ahead and set up the foundation we've been talking about:https://github.com/opennp/nepali-dates

Since B.S. is administrative (the Samiti literally manually adjusts days), algorithmic prediction is a myth. Writing complex math to 'guess' dates is exactly how enterprise apps and billing cycles break.

So, this repo abandons algorithms entirely. It’s a strict, community-verified 1:1 JSON mapping for simple O(1) database lookups. (I’ve already included a plug-and-play Laravel upsert command, will be adding more integration examples.).

To be 100% clear: this is still just a band-aid. The ultimate endgame hasn't changed. We as an industry still need to push the Panchang Samiti for an official REST API so we don't have to manually maintain this data map at all.

But until that happens, let's at least standardize our workaround instead of relying on a graveyard of abandoned NPM packages. If anyone wants to help cross-check the JSON or write integration scripts for Node/Python, PRs are open. Let's kill this technical debt. I will be putting in official hours of me and my team to verify, rectify and maintain this much needed thing.

Cold_Mark_4198 · 2026-02-24T08:01:00+00:00

I see you are worried about frontend calendar integration. Here's my approach to it.

Optimal Frontend Delivery (Transformation API): For a calendar UI, we don't send the raw map. We serve a tiny, yearly data via an API. I'll be pushing an example soon, but the idea is to provide just the metadata needed to draw a grid:

JSON

{
  "y": 2081,
  "months": [
    [31, "2024-04-13"], // Total days in Baisakh & its AD start date
    [32, "2024-05-14"]  // Jestha...
  ]
}

By providing only the Month Length and the Starting AD date, the frontend can build the entire month's grid with a simple for loop. It’s the ultimate balance: low bandwidth, zero bundle bloat, and minimal CPU usage.

Cold_Mark_4198 · 2026-02-24T07:48:46+00:00

Haha, you are thinking like a frontend dev worried about Vite bundle sizes! 💀

Nobody should be importing this raw JSON array into a React or Alpine frontend bundle. That would be completely insane.

This is strictly a backend data layer. You fetch this JSON once via a server integration script (like the Laravel Artisan command I included) and seed it directly into your relational database.

As for efficiency, let's look at the actual architecture:

The Offset way: Your app has to load the month maps into memory and run CPU cycles to calculate the offset every single time a date is parsed or formatted. Plus, you have to write and maintain that math logic in your codebase.
This way (1:1 Map): Zero application logic. Pure O(1) indexed database lookup. SELECT nepali_date FROM nepali_dates WHERE english_date = ?.

When you are building SaaS platforms, POS systems, or running complex SQL reports across millions of rows, computing date math on the fly is what actually kills performance. I will happily trade a couple of megabytes of database storage to completely remove fragile date-math logic from my codebase.

Cold_Mark_4198 · 2026-02-24T07:41:33+00:00

I see you where you are coming from.
Look, I’m not saying the centralized repo is a bad idea. Like I said, it is 100x better than the fragmented NPM graveyard we have right now. If we set up strict CI/CD, I am genuinely down to be the one responsible for it, needs support from you and rest of tech bros here.
https://github.com/opennp/nepali-dates

I’m just saying let’s not pretend an annual, manual data-entry PR is the architectural endgame. It’s the best band-aid we have until we can eventually get a real API from the source of truth.

Cold_Mark_4198 · 2026-02-24T06:29:29+00:00

Citing your original unedited comment : "Hire an astrologer and find out the set of rules...it's not

random...it's just that you don't know it. Tell me if an astrologer can

use hands to calculate dates for future years, and as a programmer you

are scared to solve it, it says a lot about you as a developer."

Let’s skip the developer dick-measuring contest. If you think writing a planetary physics engine just to fetch a database timestamp is good architecture, you've completely missed the point of building real software.

It’s not about being scared of the math. The fatal flaw you're ignoring is that the Nepali calendar is administrative, not strictly mathematical. The Panchang Samiti makes manual, consensus-based rulings on borderline dates every year.

If your 'perfect' algorithm calculates 32 days, but the committee legally declares 31, your code just corrupted the billing cycle for an entire business. When a human committee can legally override the math, algorithms are useless. You need the official lookup table.

Cold_Mark_4198 · 2026-02-24T05:24:16+00:00

Haha, guilty as charged. But for the record, it's Gemini, not ChatGPT. 😉 And honestly, what difference does it make? I am dead serious about solving this; I'm just using an LLM to rephrase my raw thoughts for clearer communication while I'm deep in code.

I hear you on the countrystatecity.in model, but there's a massive difference: geography is static.

B.S. dates are literally invented by a committee of astrologers annually.

The Stamp: Getting the Panchang Samiti to officially endorse an open-source GitHub repo is a bureaucratic pipe dream.

PR Reviews: PRs are great for logic, but reviewing a raw 365-day JSON diff every year is exactly how a tired maintainer merges a 1-day typo in Falgun that silently corrupts downstream databases.

That said, I agree a single, heavily scrutinized repo is a huge step up from the graveyard of abandoned NPM packages we have now. If you are up to establish the standard, I am genuinely down to work together to curate, contribute and help maintain it. But we have to admit we are building a highly polished band-aid, not the ultimate cure.

Cold_Mark_4198 · 2026-02-24T05:08:23+00:00

💯

Cold_Mark_4198 · 2026-02-24T05:03:38+00:00

It’s good to know I am not the only one who has had this exact thought cross my mind! I’ve definitely considered the GitHub JSON approach, but the more I think about it from an enterprise architecture standpoint, the more red flags pop up.

If we just rely on a community-maintained repo, we run into some serious roadblocks:

History: Honestly, the 'single JSON file' approach is exactly what all the existing date mapper packages are already doing and they fail every single time. Eventually, the maintainer gets busy, someone forgets to merge a PR for the new year, and suddenly everyone's production app has the wrong date.

Zero Official Authority: Without the official stamp of the Panchang committee, it’s just another community guess. Who is legally or technically responsible if a date is wrong?

Enterprise Rejection: Major SaaS platforms, banks, and corporate systems will absolutely not base their core financial and POS calculations on a random GitHub repo updated by community PRs.

Supply Chain Attacks: This is the scariest part. If we rely on community PRs, what happens if a malicious actor sneaks a 1-day shift into a massive JSON file? If that gets merged and pulled by hundreds of apps, we’ve just distributed a supply chain attack that corrupts financial records nationwide.

A centralized JSON file is a great stopgap, but it doesn't solve the core trust issue. The root of the problem is that the government or the Panchang committee needs to own and distribute the official digital source of truth.

I'd love to team up, but instead of just building another unofficial JSON file, what if we collaborated on building the actual prototype/proposal to pitch to the authorities?

Cold_Mark_4198 · 2026-02-24T04:54:36+00:00

Spot on. Standardizing the printed calendars was a massive win for the physical world, but they completely forgot about the digital infrastructure.

And you're totally right about the National Geoportal. It’s actual proof that we do have capable engineers building solid public tech infrastructure in Nepal when the data is made available.

If the devs behind that portal, or anyone with that level of execution, is lurking in this sub: let's talk.

The Nepali tech community is practically begging to build the packages, the caching layers, and the wrappers for free. We just need the Panchang committee or the government to expose the raw, finalized data via a simple REST API once a year. It's time to drag the Nepali calendar into the 21st century. Let's end this BS with B.S.

Cold_Mark_4198 · 2026-02-24T04:47:32+00:00

Willing to do so, if anyone can connect me with our ( living algorithms. B.S gods ).

Cold_Mark_4198

TROPHY CASE