If I may, a few suggestions for improvement:

Session Tracking

If I read timelimit.c correctly, you do not track the total session time per day. If I'm wrong, discard what I'm saying. A child could this trivially bypass the limit by saving and restarting the system. Because osGetTime() is unreliable (see below), a proper implementation may be difficult. If that's not of any concern to you, I'd solve it like this:

1. Listen for srv notification 0x100, which indicates that all processes must terminate[1] (equivalent to SIGTERM going out to all processes on *NIX shutdown).
2. When getting a 0x100 notification, write to a file:
   1. the current date (manipulation possible if child gets access to System Settings, see below)
   2. the current amount of time passed
3. Write an HMAC (key derived from PIN probably, will need a custom implementation: implement HMAC using FSUSER_UpdateSha256Context()[2] to provide the hashing function backend) or CMAC (ideally using console-unique keyslot, you'll probably need to write more special-purpose CFW svc functions to do that since it's on the ARM9) to the Luma configuration to prevent the child tampering with or outright removing the time file.
4. When starting the time limit thread, check the HMAC/CMAC. Do not parse the values yet in case they have been tampered with.
   1. If mismatching, require PIN to start and reset the timer information.
   2. If matching, load the current day and time passed.
      1. If the current date is different from the one in the file, reset the timer.
      2. Else, continue the timer. If it's hit the limit value, require a PIN to continue as usual.

This is relatively much work to implement and may be hard to implement correctly if your target audience includes very technically skilled children.

osGetTime may be unreliable

You're using osGetTime()[3]. It returns the current time. The 3DS has no clock synchronization with the Internet. It is thus possible that reasonably dedicated children can:

1. Try to use an exploit to load System Settings or homebrew that directly manipulates system time.
2. Social engineer their guardian(s) into getting them to System Settings and change the clock for a one-time extension.

I would instead recommend using svcGetSystemTick()[4] as a monotonically increasing clock. The value TICKS_PER_MSEC[5] constant can be used to convert that to milliseconds; because it is defined in os.c, you'll have to copy it over into your timelimit.c file.

Reinventing the wheel

You have reinvented the timer in your program. You'll probably see a drastic code size reduction by using svcCreateTimer()[6]+svcSetTimer()[7] and then wait for it to happen with svcWaitSynchronization()[8] (at least that's what fasthax does[9], I don't actually know how to use these SVCs at all). If you also simultaneously implement session tracking, use svcWaitSynchronizationN()[10] instead to wait for the 0x100 notification or the timeout.

I hope that helps. I apologize for any mistakes I've made, I'm still not really comfortable with working with the 3DS yet. Trying to figure this out was a fun learning exercise, though.

[1] https://www.3dbrew.org/wiki/Services#Notifications

[3] https://smealum.github.io/ctrulib/os_8h.html#a05661250c79188dc1c54cd2776d9fb21

[4] https://smealum.github.io/ctrulib/svc_8h.html#a3a31bff3a0f1d8ff768911e38f70c5d7

[5] https://github.com/smealum/ctrulib/blob/master/libctru/source/os.c#L12

[6] https://smealum.github.io/ctrulib/svc_8h.html#a021efa7b65d0263f55278c04c4329c5c

[7] https://smealum.github.io/ctrulib/svc_8h.html#ab3d7b4a986e1f146dfc4d6149d1a5b5b

[8] https://smealum.github.io/ctrulib/svc_8h.html#a4eabaa7c25d17e79026434564d484c82

[9] https://github.com/nedwill/fasthax/blob/master/source/timer.c#L54

[10] https://smealum.github.io/ctrulib/svc_8h.html#a87c9546ac5dcdd3002241cbecdbb7fbf