GMT Stuff and Date and Time Stuff.

use strftime to convert time to a string http://www.cplusplus.com/reference/ctime/strftime/

#include <assert.h>
#include <stdio.h>
#include <time.h>

int main(void) {
    time_t t = time(NULL);
    struct tm *tm = localtime(&t);
    char s[64];
    assert(strftime(s, sizeof(s), "%c", tm));
    printf("%s\n", s);
    return 0;
}

Select allOpen in new window

I have seen . used in dates as well in times.:   1999.12.31 23.59.59
. is often used between seconds & milliseconds or microseconds.

For offset to GMT (or rather UTC , there is a difference that has to do with adjusting time with leap seconds).
Easterly = +xx:00 hours,  westerly of Greenwich is negative offsets until they meet on the date border (+12:00 / - 12:00).

In ISO 8601 timestamps NO separators are used:  YYYYMMDDTHHMMSS.mmm although there are different formats withseparatros as well (only -) as common ground parsable dates.
https://en.wikipedia.org/wiki/ISO_8601 has a list and also has references to various date/time standards.

Slash, dash, dot, and colon is sufficient for me but some languages allow to define any character as a date separator… Go to the Windows Regional settings and you may see the most common settings for many countries. Date elements order or 12/24 hours time format is maybe more important because it can cause the most of confusion.

You are asking in SQL Server zone and SQL Server provides somehow standard way of the Datetime presentation. The datetimeoffset data type contains the current offset to GMT. Thus you may issue the following query:

SELECT TODATETIMEOFFSET(GETDATE(), 120)
SELECT GETDATE() AT TIME ZONE 'Central European Standard Time'

And you should see the local time + adjustment to GMT which is 2 hours for given TZ now.

Available Time Zones are listed in this SQL view together with the information about Daylight saving:
SELECT * FROM sys.time_zone_info

You may see some areas do have TZ offsets rounded to 15 minutes and also some areas in Pacific do have GMT+13 hours. (They don't use GMT-11 because they would have different week day from their neighborhoods which is possible "business blocker" in such case.)

I would guess nobody has implemented universal Time Zones into custom application because it is rather difficult when your SQL Servers are in one TZ, Web servers in another TZ, and users around the world... In such case would be worth to store all times in GMT and adjust the time on presentation level based on user preferences. But I am not sure whether this is enough...

Good luck!

CEST = Central European Summer Time (+2)  [ between Last Sunday Mach & Last Sunday of October],   otherwise it is (CET)  Central European Time (+1)

Many system use UTC (GMT)  as the internal clock, and times are calculated when presented.

Best is to use no delimiters for date, and minimal for time, like so:

YYYYMMDD hh:mm[:ss.sssssss] /*where hh is 24-hour clock: 15=3PM, etc.*/

The reason is that it is unambiguous. If instead you write:
2017-04-07
some people read that as Apr 7 and some as Jul 4.  
20170407
always means Apr 7.

SQL Server does not recognize "Central European Summer Time" it just knows Central European Standard Time with the Daylight saving flag set.

I don't care about the mistakes in various software...
(from timzonedata: IANA the authoritive source on this data: https://www.iana.org/time-zones
This database updated  a few times a year for places where Summertime changes are on policitcal agendas ,
voted on by parliaments on sometimes weeks before it starts.
https://www.iana.org/time-zones

# zdump -v -c 2017,2020 CET
CET  -9223372036854775808 = NULL
CET  -9223372036854689408 = NULL
CET  Sun Mar 26 00:59:59 2017 UT = Sun Mar 26 01:59:59 2017 CET isdst=0 gmtoff=3600
CET  Sun Mar 26 01:00:00 2017 UT = Sun Mar 26 03:00:00 2017 CEST isdst=1 gmtoff=7200
CET  Sun Oct 29 00:59:59 2017 UT = Sun Oct 29 02:59:59 2017 CEST isdst=1 gmtoff=7200
CET  Sun Oct 29 01:00:00 2017 UT = Sun Oct 29 02:00:00 2017 CET isdst=0 gmtoff=3600
CET  Sun Mar 25 00:59:59 2018 UT = Sun Mar 25 01:59:59 2018 CET isdst=0 gmtoff=3600
CET  Sun Mar 25 01:00:00 2018 UT = Sun Mar 25 03:00:00 2018 CEST isdst=1 gmtoff=7200
CET  Sun Oct 28 00:59:59 2018 UT = Sun Oct 28 02:59:59 2018 CEST isdst=1 gmtoff=7200
CET  Sun Oct 28 01:00:00 2018 UT = Sun Oct 28 02:00:00 2018 CET isdst=0 gmtoff=3600
CET  Sun Mar 31 00:59:59 2019 UT = Sun Mar 31 01:59:59 2019 CET isdst=0 gmtoff=3600
CET  Sun Mar 31 01:00:00 2019 UT = Sun Mar 31 03:00:00 2019 CEST isdst=1 gmtoff=7200
CET  Sun Oct 27 00:59:59 2019 UT = Sun Oct 27 02:59:59 2019 CEST isdst=1 gmtoff=7200
CET  Sun Oct 27 01:00:00 2019 UT = Sun Oct 27 02:00:00 2019 CET isdst=0 gmtoff=3600
CET  9223372036854689407 = NULL
CET  9223372036854775807 = NULL

Select allOpen in new window

https://data.iana.org/time-zones/tz-link.html   <- source for up to date zone information (including hitorical data).
http://home.kpn.nl/vanadovv/time/TZworld.html#eur

From the zoneinfo text source in the timezone database:
(file with name europe) [code[# ... I received today an answer letter from Dr. Peter Hetzel, head of the PTB
# department for time and frequency transmission.  He explained that the
# PTB translates MEZ and MESZ into English as
#
#       Central European Time (CET)         = UTC+01:00
#       Central European Summer Time (CEST) = UTC+02:00
[/zone]

Of course, IANA and Microsoft are not equal :-)

I am looking at it from algorithmic point - Imagine application which should work in different local environments (different Time Zones) some of them do have Daylight saving some others don't...

What Time Zone would you store to the database for such entities? How would you ensure the proper switching between Standard time and Daylight saving? What time would you show to users processing data from different TZs? Etc. etc.

TZ naming is almost marginal for me.

IANA names are based on the international standards etc. ..
The last part in my comment was a comment in the IANA databse from someone responsiible for timekeeping in a country.
about a few acronyms found in litterature (MEZ en MESZ)  PTB:
https://www.ptb.de/cms/en/ptb/fachabteilungen/abtq/gruppe-q4/ref-q42/time-synchronization-of-computers-using-the-network-time-protocol-ntp.html 
IMHO more an authority than some programmer in microsoft that guessed at a name.

More to the point
i would store UTC, and convert times where needed.  (then the times will always be correct match to any wall clock on earth [ when using the correct time tables ] which IANA is so kind to provide for times from 1920-ish onwards. The IANA sources are full of references where the DST skips were obtained from and even that there is no accurate time keeping in several areas ... Like Berlin environment in 1945.. There were 3 timezones active in that city at the same time... so more context would be required to give an accurate time at that moment.

Using UTC  no one needs to wory about time zones. except for the viewer. (The viewer in US would see the real times based on their own clock).  wich would correspond anywhere else... and if  the viewer needs a different presentation, let the view choose a zone next to their date field.

That is not so simple. I would agree to UTC storing. To have good tables containing time zone info is a good start.

The presentation layer is more complex in the case of data entering users sitting in a different TZ than the data subjects.
So you have to recalculate local times between two or even three TZs, you have to take care of different switch times between Daylight saving and Std times. Imagine Web application. Some values are calculated on the web server some other values are calculated in JS code on the client  etc. etc.

That's why i indicated that the timezone for display should be selectable next to it if you need to enter/view data in a different timezone.

I'm still looking for "C" examples on how to compute and build a GMT (+ or - 07:00 timezone name and time).  I know when it is daylight savings time and not. But I'm waiting for a knowledge verified expert to come thru.

what is the problem with the code presented @ https://www.experts-exchange.com/questions/29145175/GMT-Stuff-and-Date-and-Time-Stuff.html?anchorAnswerId=42859112#a42859112

In Unix (& C runtime library) the time is a linear value. 32bits integer (currently, 64bits is in the works) which keeps the time measured in seconds since Jan 1, 1970. (Unix EPOCH).
so handling time is just adding & subtracting 3600 for changing one hour etc.

The earlier code is good for formatting.

strftime() is formatting time
time() = read the wall clock.   (seconds since jan 1, 1970)
localtime()    = assuming the wallclock   convert with timezone settings of the system to a time value split in (year, month, day,
gmtime() = same for Greenwich time . (same structure, and based on the wall clock time without offset).

adding an hour is adding 3600 to the timevalue in time_t. etc.