Your computer program is free to try to guess your timezone, free to store the fact that it guessed, and show you the guess, and give you a convenient UI for correcting the guess if it gets it wrong, free to offer some preferences to control the way it guesses... but it should never store a raw 11:32 (as a time, not a string) in its memory at any point in the process. That's a recipe for software worse than your paper notebook, because it tries to wake you up at 2:32 am localtime for your meeting. Oops.
But in general... computers and ambiguity don't get along. Dealing with that by writing sloppy programs is a recipe for disaster. Sounds like you're not writing down dates anyhow, just chunks of text that you don't expect a computer to interpret. If you do expect it to interpret your date you better have a specific time in mind or it's not going to do the computer any good anyhow.
free to try to guess your timezone, free to store the fact that it guessed, and show you the guess, and give you a convenient UI for correcting the guess if it gets it wrong
This is far less convenient than pencil and paper.
it tries to wake you up at 2:32 am localtime
Yes, in order to instruct the computer to do something at a particular time, you have to reduce it to absolute time (although I think this is best done by storing the local time and the time zone, rather than the absolute time, since the time zone may change between the time I write down the time and the time I use it). But there are lots of times I write down that can be usefully processed without being reduced to absolute time; for example, if I have a bunch of times in the same (unspecified) timezone, I can sort them and compute intervals between them. (...usually.)
There's a difference between writing sloppy programs and writing programs that can be successfully used sloppily.
Then just write your strings-that-represent-timelike-things in your text editor and be done with it. What, exactly, is your point? You think that because you don't need your personal strings to actually denote time, this isn't a problem that ever needs to be addressed precisely and accurately?
As I said in the comment you're replying to, there are lots of times I write down that can be usefully processed without being reduced to absolute time. My text editor doesn't know how to do that. (Much.) I'm writing here precisely because I think it's a problem that often needs to be addressed precisely and accurately, and neither automatically falsifying data on input, nor making an application that's harder to use than pencil and paper, is an acceptable solution to the problem.
You're doing a bad job of distinguishing between a feature you personally want in an application, and the actual problems associated with storing times. As has been pointed out, there's no such thing as a time without a timezone. '12:30', the thing you want to write, is just a string. Acting like it's more than a string in your application is fine - strings are very flexible - but that's a completely different topic than the one at hand. You don't seem to be grasping this.
I guess the challange is to enter a precise time using a computer, and make it as easy as writing an imprecise time on paper.
I don't know where to go from there. On paper, you can assume than a time without a timezone is in localtime. That is fine, since it takes effort to move paper from one timezone to another. If you know the paper is from a different timezone, you might switch your interpretation, even without the timezone stated explicilty.
But in general... computers and ambiguity don't get along. Dealing with that by writing sloppy programs is a recipe for disaster. Sounds like you're not writing down dates anyhow, just chunks of text that you don't expect a computer to interpret. If you do expect it to interpret your date you better have a specific time in mind or it's not going to do the computer any good anyhow.