Like I said, I really would recommend the official training. The Siemens PLC's think a little bit differently from the AB ones, and have a different memory structure. Programming best practices change drastically across brands. However, here are some basics to hopefully help get you started.
READER BEWARE: lots of text follows, and this is the 2nd 4 o'clock I've seen today, but I'm not yet sleepy. Hopefully this is mostly coherent. I'm trying to define all my acronyms, but no promises. When I sit down with an engineer new to these PLC's, I find it usually takes at least 2-4 hours until he is mostly comfortable with what I have covered below. If you this doesn't quite make sense, hopefully it at least gives you an idea of what you need to learn.
The most important thing you can do when you have a question is hit F1. The help system is pretty good, and will usually bring up the help file for whatever you have highlighted.
There are a few different kind of blocks in the Blocks Folder of Simatic Manager. Every block has a number, and they can also be assigned symbolic names. The first type is OB's, which are Organization Blocks, which are the blocks that the system calls for various reasons. Each OB has a number, which defines it's purpose: OB1 is the main program scan, OB86 is a block called when a remote IO rack has an error, and there are many others. One you might want to look at is OB10, which is a Time-of-Day Interrupt, if you want to call code at a specific time of day. Basically, the OB's are all the different system entry points for the code. Most of the time, most of the PLC code is called from within OB1, but it sometimes makes sense for a little bit of code to be called in various interrupts, for boot up, error-checking, a more cyclic scan time, fast reaction to a hardware input, or a number of other reasons.
The second type of block is a DB, which is basically a big memory area used to store structured data. If it makes you comfortable, RS500 programmers often emulate the behavior of the data tables by creating a data block that is an array of integers, a DB that is an array of DINT's, and whatever else you need. However, the "Siemens Way" would be to group your variables in a way that matches your process logic. You can create structures in these data blocks if you choose, or leave them as a flat data table. As you enter the variables into the DB, you can assign them a name and a data type, and it automatically assigns the appropriate memory address in the DB structure. A "Shared DB" is a DB that can be accessed globally in the program, and can be edited to add or delete variables as the programmer needs.
Another type of block are the FC's (functions) and FB's (function blocks). These are chunks of code that can be self contained. They can have defined input and output parameters, and can provide great modularity and flexibility to a program. It allows you, for example, to create a standard program that controls every motor the same. You simply write the code once, and then call the block every time you need it. It is possible to declare locally scoped tags in each block, to separate the code in the block from the code in the system.
The main difference between an FC and an FB is in how they store their internal variables. An FC has only temporary memory, and forgets all of its data as soon as it stops executing. An FB, on the otherhand, is paired with a DB (called an instance DB). It stores all of its data in the DB, which allows you to store data from cycle to cycle. However, you need a new instance DB for each time you call the FB, so that the FB can keep track of which data belongs where. The structure of these instance DB's is locked to the structure defined for the local variables in the interface of the FB. It is possible to write to the instance DB directly from other places in the PLC program, but it is considered very bad programming practice to do so; among other reasons, it can cause very difficult to troubleshoot behavior.
The example I typically use to show when you might use an FC vs an FB is this: An FC is great for something simple like an addition block. Two inputs, one output, nothing to remember. But if you need to calculate something like a moving average, then you need an FB, because it has to remember what the sum was from last scan.
It sounds like you've already looked at the library of blocks Siemens provides. Some of them, the SFC/SFB (System function/function block) are built into the PLC firmware. However, the library provides many other blocks as well, that can be useful. You already found the SFB1 to read the system time. You can also find FC's (regular FC, not SFC) that add, subtract, and compare times. I'm not sure why Simatic Manager includes these blocks in a library instead of with the rest of the PLC instructions, but I suspect the universe has many mysteries.
A basic program would have most of the code called from OB1. OB1 will have some logic in it, and then probably some calls to FB's and FC's, which then can call more FB's and FC's inside them. The nesting of blocks within blocks can go pretty deep, but doing it this way really helps keep the code more organized. It is generally considered a good idea to use the FB's and FC's to write code you can call multiple times, if you have common functions. Sometimes it is simple things like a custom scale block, or a motor/valve control block. I've also seen much more complicated blocks built to parse XML strings sent across TCP/IP. It all depends on the process, the programmer, and what makes the most sense.
The inputs/outputs are written to with a format that first indicated what memory area it is, then how much data you want, then where the data starts. For example, IW4 reads the word that starts at input byte 4: I = Input, W = Word. The different types of memory areas are I (input), Q (Output), M (Memory). The M memory is separate from the DB's, and is generally less structured. The memory sizes are D (double word), W(Word), B (Byte), and if none is listed, then it is a bit access, which will also specify which bit. Something like Q5.2 reads the second bit of byte 5 in the output area.
Although these are all absolute addresses, you can declare a symbol name (tag name) in the symbol table. This allows you to do tag based addressing in the PLC code, which many find beneficial. It is important to note that when you create a symbol you give it a type, but these types can overlap with each other. MD0 is made up of MW0 and MW2 which is made up if MB0, MB1, MB2, and MB3. It will allow you to try to use MW1, but MW1 overlaps with MW0 and MW2. It is almost always recommended to stick to even numbers for Words, and multiples of 4 for double words.
Data Blocks are addressed in a similar manner, but it is not quite the same. The easy way is to address it symbolically: <Data Block Name>.<Variable Name>. The period is used to denote where the Data Block ends and the variable begins. You can also refer to it based on the absolute address: for example, DB1.DBW2. Note that it is similar to the Memory area, memory size, then where to start, for the I/O/M. The "DB1" would refer to data block #1. For the memory sizes, DBD means double word, DBW means word, DBB means Byte, and DBX means bit. Note that this is different from before, where bit had no prefix. Instead of something like I0.1, you would use DB1.DBX0.1.
I know that is a huge brain dump of info, I hope it helps point you in the right direction.
I'll leave you with one final tip, which you may have heard before. The Siemens software often gives you many ways to perform the same task. As an example, a couple days ago, I discussed with someone three different ways to assign IP addresses and device names to Profinet IO. He didn't need to use all three, he was just trying to decide which method was easiest for him. Personally, I've come to like the flexibility of the S7 family, but it can be very daunting at first.
And now, I'll attempt to go to bed. I drank way too much caffeine driving home from Easter and I couldn't get to sleep. I've only got an hour or so before my alarm is set to go off....
