Day 0 : All aboard the blog train
This post was initially intended to be short and concise. However, as Boromir famously said, one does not simply get things working in first attempt.
Remove cobwebs from the old website
It has been almost 4 years since this website was first created using Hugo. I had hoped it would prompt me to start documenting my activites online but it did not come to fruition. After being propped by my old colleague to gain visibility, I decided to finally revisit this website and create a series to posts to track my work.
Should be easy, right. If only!
The various shades of Hugo
First line item for upgrade to the website was to remove some old pages. To begin with, the website didn’t have much content. Cleanup of outdated pages or placeholder text was the obvious choice. I made the changes locally and pushed them without testing anything locally.
In case you wonder why, this is a small website at the moment. Any breaking changes are acceptable since the cost is a rarely visited being down for few minutes. Not something you want to do on a high traffic website anytime. This also tells me if I need to fix anything in the deploy pipeline. After all, I’m running it after 4 years.
The pipeline noticed a new commit, attempted to clone the project but failed. My old access token failed and I need to update it. As they say, every fix today avoids a failure in future!
Once the token was updated, deployment went smooth.
Not Ides of March : 3rd of March
To test things out, I created a draft post and tested it with a server locally (configured to show draft posts). This created a new entry, but with the wrong date for the post. What!
As you can notice, the two posts have correct date time information in the tags but the display content is incorrect.
- 2026-03-17 displayed as 2026 March 3
- 2021-03-19 displayed as 2021 March 3
Super weird.
Debugging in the age of LLM
The obvious way to find a solution these days is to use the error message as prompt message to a LLM. For the new age power user, copying may too slow. Anything short of LLM integration into all open terminal is obsolete. This old fart still likes to do
Sonnet (by Anthropic) quickly inferred it was an issue with Hugo theme files in the project. $dataFormat was flagged as an obvious typo for $dateFormat, leading to incorrect date generation. I manually (yes, manually) updated the flagged typo and prayed to the gods of 1s and 0s. Do we have a fix?
NOPE.
I asked the model to take another stab at the problem. It recommended a simple yet confusing change in the project configuration file. Below is the diff:
-dateFormat = "2006 January 1"
+dateFormat = "2006 January 2"
Now why would this be a problem and need a fix? Moving to January 2 will fix my problem? Will this be as groundbreaking as moving to the Gregorian calendar?
As we all eventually learn in life, we can either question if something will make a difference, or give it a shot and notice if anything changes. I made the change and went back to the altar of 1s and 0s. Did it work?
YES!!!
Date formatting in Go f*** yourself
After going through the time package documentation for Golang, asking the LLM to help me understand it, then browsing the code for Format method and finally just testing code in Golang playground, I gave up.
I mean, I understood how the time format worked but failed to recognise the benefit of breaking standard date format convention. Time, energy and token spent to find an esoteric convention.
I’ll spare you the headache of trying to figure out the convention for our discussion here. What needs to be understood is how the date format was interpreted.
2006 January 1 was interpreted as:
2006: Return the year from given time objectJanuary: Return the month in full text form from given time object1: Return the month in form of number from given time object
Stumpted, right? Changing the value from 1 to 2 switched from returning month to returning day.
Learnings
- Golang has weird date format.
- LLMs speed up debug but are prone to chase red herrings.
Fin
Boromir was right.