Kokosa's Intensive Care Unit | Kokosa's Blog

the TZ Bug in Chill with You on Linux

Sun, 08 Feb 2026 00:00:00 GMT

What’s This About

There’s a game on Steam called Chill with You ~ Lofi Story (is it even a game? it’s basically a pomodoro timer!). It’s one of my favorites - the protagonist is adorable and provides great companionship.

The setting is that you and the protagonist exist in different parallel universes, so I always assumed the time difference between the game and my local time was intentional. I never bothered to look into it.

Until the 1.2 update (January 27th), when I saw a comment in Steam’s discussion board: basically saying that when running this game on Linux with Proton, the in-game time always shows UTC+0.

For those unfamiliar with UTC (Universal Coordinated Time), here’s a simple example: I’m in UTC+8, so if my actual time is 8:00 AM, the game would show 0:00 AM - an 8-hour difference.

Wait, what? So it wasn’t some parallel universe setting after all, just the timezone not being read correctly. No wonder it was exactly 8 hours off.

Problem Analysis

It’s actually a pretty simple issue, and I quickly found the cause: Proton-run Windows programs can’t correctly read the Linux system’s timezone information. On Linux, timezone data is usually stored in /usr/share/zoneinfo/, while on NixOS it’s in /etc/zoneinfo/.

The solution is simple - just manually specify the timezone in the launch options. Go to Steam → Game Properties → Launch Options and add:

TZ=Asia/Shanghai: Sets the timezone to Shanghai (Beijing Time)
TZDIR=/etc/zoneinfo: Specifies the timezone file directory location

It should look something like this:

TZDIR="/usr/share/zoneinfo" TZ="Asia/Shanghai" %command%

After adding these launch parameters and restarting the game, the time displays correctly. 9:31 is now 9:31.

Something like this, it was originally showing 1:31

Afterword

That pretty much solves the problem. I also replied to that discussion comment with the solution. If you’ve encountered the same issue, I hope this post helps you.

By the way, I use NixOS, so normally I should use /etc/zoneinfo instead of /usr/share/zoneinfo, since NixOS doesn’t have the /usr/share/zoneinfo directory. However, this still works because Steam’s environment handles it for you.

Belike:

~ $ steam-run ls /usr/share/zoneinfo
Africa     Egypt      Hongkong     Mexico    ROK
America     Eire       HST     MST     Singapore
Antarctica  EST        Iceland     MST7MDT   Turkey
Arctic     EST5EDT    Indian     Navajo    tzdata.zi
Asia     Etc        Iran     NZ     UCT
Atlantic    Europe     iso3166.tab   NZ-CHAT   Universal
Australia   Factory    Israel     Pacific   US
Brazil     GB        Jamaica     Poland    UTC
Canada     GB-Eire    Japan     Portugal  WET
CET     GMT        Kwajalein   posix     W-SU
Chile     GMT+0      leapseconds   PRC     zone1970.tab
CST6CDT     GMT-0      leap-seconds.list  PST8PDT   zonenow.tab
Cuba     GMT0       Libya     right     zone.tab
EET     Greenwich  MET     ROC     Zulu

~ $ ls /usr/share/zoneinfo
lsd: /usr/share/zoneinfo: No such file or directory (os error 2).

Rebuilding My TG Forward Bot

Thu, 18 Dec 2025 00:00:00 GMT

The Beginning

The forwarding bot I was using was Node Forward Bot. I used it for quite a while, but kept getting bombarded with ads. Looking again, the project had been abandoned for a year. NFD2 isn’t open source (I think? Couldn’t find the repo), so I hadn’t tried it. I don’t know if it has ad blocking either. So I decided to build another wheel for my own use.

Keyword filtering?

First I tried stuffing in a bunch of sensitive words to auto-block. Then I got results like blocking x86_64 (for “64”), Steam platform exclusive (for containing banned substring), Python scripts (for “scripts”), listening port (for “listening”)… yeah, not great.

How about regex?

Ugh… clearly this path wasn’t working. So I listened to friends and tried writing a bunch of regular expressions. But as we all know, Chinese spam is wild: weìrd sp4cing, 微 P 嗯, emoji puzzles… Can regex really catch all these? Maybe, but my brain definitely isn’t that powerful (sweat), so I decided to use LLM for moderation.

Gemini! Yes!

I needed a model that’s as fast as possible - doesn’t need to be super smart, just able to understand language. At the time I didn’t know Google had cut AI Studio’s quota again. Google has a model called gemini-flash-lite that seemed suitable for content moderation, so I used it. Wrote a simple Prompt to have it judge user input and output SAFE or UNSAFE.

const payload = {
  contents: [
    {
      parts: [
        {
          text: `
            # Role
            Content Moderator API. Output one word only.
            # Rules
            UNSAFE if:
            - Real human nudity/sex
            - QR codes/spam/ads
            - Real gore/shock content
            - Illegal content promotion
            SAFE if:
            - 2D/Anime/Cartoon (even suggestive)
            - Normal photos/text/screenshots
            # Output
            One word: "SAFE" or "UNSAFE"
            Analyze: ${JSON.stringify(text)}`,
        },
      ],
    },
  ],
};

There’s a slight delay, but it’s negligible. Compared to traditional rule matching, LLM can understand context and semantics with much lower false positive rates. The downside might be cost, but Gemini has a free tier - not much though. With three API keys I get about 60 calls per day, barely enough for ad blocking.

Refactoring the entire project

Since I’d already changed so much, might as well refactor the whole project. The original code architecture was messy, all logic crammed in one file, painful to maintain (though this kind of project barely needs maintenance).

So I battled with various LLMs for a night - they all went stupid. Finally downloaded Antigravity and refactored the whole project into a modular architecture in one go:

.
├── src
│   ├── ai.js
│   ├── config.js
│   ├── handlers
│   │   ├── admin.js
│   │   └── guest.js
│   ├── index.js
│   ├── storage.js
│   └── telegram.js
└── wrangler.toml

I have to say Antigravity is really good. Free Claude Opus 4, generous quota.

Implemented these features:

Feature	Description
AI Content Moderation	AI-based harmful content detection
Ban List	View all banned users
Stats System	Message count, user count, AI blocks
Multi API Key Rotation	Fucking Google

Multi API Key rotation is to handle Google’s Rate Limit. 20 API calls per day - who can use that? It used to be 100 per day. Gemini CLI and Antigravity have generous quotas, but the API is stingy.

The whole project runs on Cloudflare Workers (nice touch from the original project - convenient, useful, and free). Completely zero-cost solution. LLM is also free. The whole project is just JavaScript.

Finally pushed the code to GitHub, open sourced under BSD2 license.

Link~

GitHub: kokosa-forward-bot
LinuxDo: KFB — A Telegram DM Forward Bot with AI Moderation

From configuration.nix to Flake

Sat, 04 Oct 2025 00:00:00 GMT

What’s up

With less than 240 days until the Gaokao (college entrance exam), time is tight and I don’t have much time to blog. But after being urged by friends, I figured I should at least write one post. Actually, I’ve been keeping a diary, but it’s too personal to share publicly.

Amid all the busyness, I managed to get some things done. For example, last weekend I finally set up Flakes, which I’d been wanting to do for a while. With the help of CodeX CLI, it didn’t take too long - I let the AI Agent handle the trickiest parts, and it was almost a one-shot success. Here’s my current directory structure:

.
├── flake.lock
├── flake.nix
├── home
│   └── modules
│       ├── dae.nix
│       ├── fzf.nix
│       └── niri.nix
├── Justfile
└── nixos
    ├── configs
    │   ├── dae
    │   │   └── config.dae
    │   └── niri
    │       └── config.kdl
    ├── hosts
    │   └── kokosa
    │       ├── default.nix
    │       └── hardware.nix
    └── modules
        ├── boot.nix
        ├── desktop.nix
        ├── locale.nix
        ├── networking.nix
        ├── nix-settings.nix
        ├── packages.nix
        ├── security.nix
        ├── services.nix
        └── users.nix

Of the programs managed by Home Manager, only fzf is actually in use. The other two are planned for future use, so I’ve written the configs but they’re disabled.

Why switch from Channels to Flakes?

Compared to configuration.nix, Flakes solves many problems. It can lock all packages and dependencies to specific versions - a single config file can precisely restore an entire system down to version numbers and commits. Channels, on the other hand, follow updates and can’t do this.

Feature	Channels	Flakes
Dependencies	Implicit (channels)	Explicit (inputs)
Rebuild	`sudo nixos-rebuild switch`	`nh os switch .`
Reproducibility	Depends on individual channel versions	`flake.lock` ensures consistency
Development	`nix-shell`	`nix develop`

nh is a NixOS helper tool. Its support for configuration was a bit mysterious, but after switching to flakes I found it to be a really useful tool. Highly recommended!

Additionally, Flakes can easily reference other Flakes through Inputs, like sodiboo/niri-flake, enabling declarative management of software that isn’t officially supported. I don’t actually plan to use HM to manage Niri though.

For development environments, you might have noticed that many open source projects on GitHub/Codeberg now have a flake.nix file in their root directory. With this file, you can easily reproduce the entire development environment with Nix, isolated from your main system - all with just one command: nix develop. Most modern Nix projects (even non-Nix projects) are starting to use this because it’s genuinely useful.

Of course, there are some drawbacks, like unstable APIs (still “experimental” since 2019) and mandatory Git dependency. There are other pitfalls too. Determinate Nix solves some of these, but it’s partially closed-source (like nixd). Despite the pitfalls, Flakes is more convenient than Channels, and with AI managing my configs, the migration wasn’t too complex.

File showcase?

First, flake.nix:

{
  description = "Kokosa's Nix Flake";

  inputs = {
    # Nixpkgs & NUR
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    nur.url = "github:nix-community/NUR";

    # Flake-parts
    flake-parts.url = "github:hercules-ci/flake-parts";

    # Home Manager
    home-manager = {
      url = "github:nix-community/home-manager";
      inputs.nixpkgs.follows = "nixpkgs";
    };

    # Other
    hid-bpf-uclogic.url = "github:dramforever/hid-bpf-uclogic";
  };

  outputs = inputs @ {
    nixpkgs,
    flake-parts,
    ...
  }:
    flake-parts.lib.mkFlake {inherit inputs;} {
      systems = ["x86_64-linux"];

      perSystem = {pkgs, ...}: {
        formatter = pkgs.alejandra;
      };

      flake = {
        nixosConfigurations.kokosa = nixpkgs.lib.nixosSystem {
          system = "x86_64-linux";
          specialArgs = {
            inherit inputs;
          };
          modules = [
            ./nixos/hosts/kokosa/default.nix
          ];
        };
      };
    };
}

The single file imported, default.nix, is what used to be my machine’s configuration.nix, though it’s now been completely transformed. The original massive file has been sliced into many smaller files and unified through imports. Besides that, this file only contains some Home Manager settings.

imports = [
    inputs.home-manager.nixosModules.home-manager
    ../../modules/nix-settings.nix
    ../../modules/networking.nix
    ../../modules/security.nix
    ../../modules/packages.nix
    ../../modules/services.nix
    ../../modules/desktop.nix
    ../../modules/locale.nix
    ../../modules/users.nix
    ../../modules/boot.nix
    ./hardware.nix
  ];

The rest isn’t much different from my old config. They haven’t been uploaded to GitHub yet, but I’ll probably get around to it when I have time. Here’s a screenshot:

I love this wallpaper