Storing it purely as a numerical offset isn't enough, because you need to know the location. Does DST apply? When does DST start? Did DST exist in 1971? Will DST exist next year? Will it be DST next week? I'm not sure what you intended with "DST-2" in your proposed format exactly, but you really need a database for these things since there isn't a universal agreement on these things. Maybe there ought to be, but there isn't so we'll have to deal with that.
Plus countries change timezones. I can set it to "+8:00" and in two years my country changes its timezone and now the stored information (and thus my time) is incorrect. We also need to know on which date the change takes effect, because showing the wrong time for tomorrow or next week would otherwise show the wrong time.
I actually store timezones as "<country>.<zone>". e.g. NL.Europe/Amsterdam. This is because users select the country first in the UI (rather than a zone), and this way it will always be clear which country the user selected. It would be confusing at best, and potentially offensive, to show a different country later.
Plus countries change timezones. I can set it to "+8:00" and in two years my country changes its timezone and now the stored information (and thus my time) is incorrect. We also need to know on which date the change takes effect, because showing the wrong time for tomorrow or next week would otherwise show the wrong time.
I actually store timezones as "<country>.<zone>". e.g. NL.Europe/Amsterdam. This is because users select the country first in the UI (rather than a zone), and this way it will always be clear which country the user selected. It would be confusing at best, and potentially offensive, to show a different country later.