As soon as you handle dates or times, handle them in UTC.
Why UTC? Because it’s Coordinated Universal Time. Universal means it’s a standard understood anywhere. This way you can reuse your code anywhere and move safely your hosting from a country to an other.
“Is using an other timezone really bad? My application is on a private network in only one city.”
Yes, it’s evil. No matter what your application is for. Even if you’re 100% sure today every user of the app is on the same timezone, you cannot be 100% sure of the future and if some day you need to use some of the app data, you will be happy to have dates in UTC because it will be the easier format to export and import them elsewhere.
Then, last reason is UTC is the most reliable timezone. All other timezones can change: a country government can decide to change the timezone offset of its country/regions, a country can be split/merged, cities sometimes change their names so if a timezone uses the name of this city, it can change too. Governments can also add/remove the DST (daylight saving time), change the start/end dates of it.
About DST, timezones with DST are even less reliable than others, because with DST you get a variable offset (+/- 1 hour depending on the date) and day duration become variable (23 hours when you lose an hour, 25 hours when you win it, 24 hours for all other days). Then during the 25 hours day, you will have ambiguous time: 4 nov 2018 1h30 in Chicago can be two different moments (1h30 UTC-5h or 1h30 UTC-6h) no way to know it if you do not store the timezone offset of every date, do you store the time offset in your database for every date? I guess not.
So you can trust UTC, more than any other, UTC will always be UTC, its name will not change, days in UTC are always 24 hours, each UTC date-time matches only one single instant, it’s location-agnostic and its offset is always 0 (as 0 is the perfect default for a number value, it’s also the perfect one for timezone offset).
“OK, right, but now then, how to display those dates in an other timezone, because my users do not understand UTC.”
It can differ a bit depending on the programming language but first let use an object (rather than a string or a timestamp): Date in JS and Java, DateTimeImmutable or DateTime in PHP, DateTime in C# and Ruby, datetime in Python, time in Go, chrono::DateTime in Rust, etc. All those classes have some methods to set the timezone of the date or have timezone options for some outputs.
If you’re in a context with a back-end and a web front-end. You don’t even need to format it server side, you can just turn the date into a UTC ISO string, such as: “2001–12–31T23:59:59.000000Z” (here too, every language can return this string in a standard way, just google “Output datetime ISO string in PHP” and replace PHP with any language). Be sure the string ends with “Z”, it’s the UTC timezone flag. The second decimals can vary from 0 to any number, JS will handle as many it can (generally 3) and ignore others.
Then you can pass this string to the browser (via a JSON API, hidden in a data-xyz HTML attribute, etc.), then translate it with JavaScript using your client’s browser settings or settings you saved in your users base:
This will output “1/1/2002, 5:29:59 AM” using Calcutta timezone (+5:30) and en-US format.
To go further in JavaScript, you may consider using momentjs: https://momentjs.com
To go further in PHP, I recommend the Carbon library: https://carbon.nesbot.com
Those both libraries have many compatible methods, so learn to use one of them is easy if you already know the other.
Last, if you follow the rules mentioned here (work with UTC dates, store UTC dates and change the timezone only the very last moment before displaying them to the user), you should find very easy to handle your dates with these libraries.
If you have references of equivalent libraries in other languages, do not hesitate to put them in comments.
