Develop Reference

Display time zone code for users

Have a site for training webex events. Our company is located in several different timezones. In the past everything has been converted to Pacific time (where we are headquartered). Trying to focus more on user experience and make things more local and less about HQ.
So all the times are shown in local time, but this is now confusing users because they don't expect it. I'd like to add three letter initials (PST, CMT, EST, HAST or HST, etc.)
As I'm looking into this I'm keep getting referred back to moment timezone. We are already using moment for other date/time stuff, so that would be awesome.
But all the timezone examples are like this:
moment.tz([2012, 0], 'America/New_York').format('z'); // EST
Basically it seems like you already need to know what timezone the user is in. If I already knew what timezone they were in I wouldn't need moment to tell me. Also the documentation says:
...By default, moment objects are created in the local time zone....
I'm located in Portland, Oregon, javascript new Date() shows (PST) (in Chrome at least), but moment.tz().zoneAbbr() is UTC, so clearly not my local time zone.
I found this thread that recommends using jsTimezoneDetect.
moment.tz(new Date(), jstz.determine().name()).format('z')
I understand why this is a complex thing given locations around the world and different daylight savings schemes. But I have to wonder -- am I missing something? Is there some easier way to do this?

Print the time for a given location

Supposing I have
a date (i.e. an UTC timestamp),
a location (e.g. "Paris") that I may encode as I wish (and which isn't the one of the browser),
no permanent internet access
then what can I do if I want to format my date for this specific location, correctly dealing with daylight saving time when/if it occurs ? I'd prefer a standard based solution. I expect the solution to either include a reliable table of some sorts or to call some browser/computer magic.
Of course, as the offset is dependent of the moment, I can't just store the location as an offset.
Here are 2 points which ease the problem :
I won't deal with dates before 2010
if some country decides to change the rules regarding its timezone, it's acceptable for me to release a new code/library

Have a look at moment.js which support localization in a pretty nice way as well as time zones.
For the location issue, I would say you will have a really hard time solving that without an Internet connection. I would say the only way to solve it is to have your users enter a country (and maybe time zone) manually.

How do you calculate if a specific time in a specific time zone is affected by daylight savings using JavaScript?

I know that new Date().getTimezoneOffset() accounts for the local user's timezone & DST, but how to calculate the current local time in say Timbuktu for an arbitrary time in the future?

JavaScript does not have a timezone database built in to the language (as can be seen by perusing the spec). Instead it only has the concept of "local time" and "UTC time," with there being only one local timezone.
It is possible there is a browser API for getting a timezone database, but I have never heard of it. There are some third-party projects that interface with such databases; a quick search turns up timezone-js.

I doubt there is any algorithm that could give you what you want. The nations of the world often choose not to follow the standard time zone rules. Worse the changeover dates for DST are different.
There are 3 sources that I can think of to check:
Jeppesen, a subsidiary of Boeing, is the primarily civilian supplier for the entire world for aeronautical navigation information. I just checked my old Jeppesen manual that I ceased getting weekly updates for when I retired 13 years ago. It gives the time zone for all major airports in the world and the dates of their DST change. Go here for contact info. I would suspect that by now it's conveniently available electronically, but Jeppesen doesn't give anything away for free.
ICAO, the International Civil Aviation Organization (part of the UN now I think) would I think maintain that information, but I'm not so sure about the DST data. Their data, I believe, is available either free or for a nominal charge.
IATA, the International Air Transport Association, might also maintain that data.
I would think that the last two organizations might respond favorably to a simple request for a URL with that data if they know of one.
Also, if can get ahold of any airline dispatcher working international flights, they would have to have that information available.
Also, check this and others you'll see if you Google "airline time zone and dst data."

The easy part is accounting for timezones. You can find the default (+0) timezone by just subtracting timezone*60*60 seconds from the date, then adding the new timezone*60*60 to the date.
Then it's just a matter of making the time you want, using:
d = new Date(year, month, day, hours, minutes, seconds, milliseconds)

Time Zone Sensitive Date and Time Display in Web Applications?

I am looking for recommendations on displaying times in a web application in a time zone other than the user's current time zone.
We store our dates/times in UTC/GMT in the database, so it is not an issue to format the time for UTC/GMT or the user's current time zone. However, in other situations we need to display the time from the point of view of an arbitrary time zone (i.e. every date/time on this page is in Eastern, regardless of whether or not the user is in West Coast, Central, Eastern, etc.).
In the past we have stored offsets or time zone info, then done the calculations in server code in .Net or else we have done some client-side manipulations in javascript that I would prefer to avoid, since it all becomes very dependent on javascript and the user's browser. I'd like to know the best way to do this in a more client-side/MVC type application.
Here is an example:
Date stored in db: 1302790667 (Thu, 14 Apr 2011 14:17:47 GMT)
Converted date displayed for a client in Central time zone: Thu Apr 14 09:17:47 2011
Date I actually want to display, always in Eastern time zone: Thu Apr 14 10:17:47 2011
In the above example, it's easy to get the time in UTC (#1) or the user's current time zone (#2) but it is more difficult to get #3. My options seem to be:
Store offsets or time zones in the db and do calculations on the client - this is what we've done in the past with .Net but it seems even messier in client side code is the path we are currently trying to avoid.
Do the conversion on the server and send down a full date for display to the client - client receives a string ("Thu Apr 14 10:17:47 2011"). This works but it's not very flexible.
Do the conversion on the server, break it into parts and send those down to the client, then put them back together. ("{DayOfWeek:Thu, Month:Apr, Day:14, Hour:10, Minute:17}"). This gives us the correct data and gives us more flexibility in formatting the date but it feels a little wrong for this scenario.
Any other options ideas? How do others handle similar situations? Thanks.

Our results:
I tried out a few libraries like Datejs, MS Ajax, etc. and I was never very happy with them. Datejs didn't work at all in a few of my test cases, is not actively maintained, and seemed to focus a lot on syntactic sugar that we don't need (date.today().first().thursday(), etc.)
We do use jQuery for some basic date/time parsing.
I came across a lot of "roll-your-own" client-side date conversion "hacks", most of which only addressed the conversion to UTC, started off working fine, and then eventually fell apart on some edge case. This one was the 90% solution for a lot of standard UTC conversion but didn't solve our "arbitrary timezone" issue.
Between the code complexity the conversion routines added and the bugs they seemed to cause, we decided to avoid client side date processing most of the time. We do the date conversions on the server with our existing date handling routines and pass the formatted dates or info down as properties to be used by the view. If we need a separate date, we just add another property. There are usually only a few properties that we need at a time (i.e. EventDateUTC, EventDateLocal, EventDateAlwaysAustralia, and EventDayOfWeek).

I offer the suggestion that you look into the Datejs library. It offers a bunch of extensions to basic JavaScript date manipulation, including a "setTimezone()" method and flexible ways to convert a date into a formatted string for display.
I usually hesitate to suggest libraries when their use is not explicitly allowed for in questions, but Datejs isn't very large and it's pretty solid (even though it's called an "alpha" release). If you'd prefer not to rely on something like that, you might want to look at it anyway just to see the basics of how its extensions were implemented.

Localize dates on a browser?

Let's say I have a date that I can represent in a culture-invariant format (ISO 8601).
I'll pick July 6, 2009, 3:54 pm UTC time in Paris, a.k.a. 5:54 pm local time in Paris observing daylight savings.
2009-07-06T15:54:12.000+02:00
OK... is there any hidden gem of markup that will tell the browser to convert that string into a localized version of it?
The closest solution is using Javascript's Date.prototype.toLocaleString(). It certainly does a good job, but it can be slow to iterate over a lot of dates, and it relies on Javascript.
Is there any HTML, CSS, XSLT, or otherwise semantic markup that a browser will recognize and automatically render the correct localized string?
Edit:
The method I am currently using is replacing the text of an HTML element with a localized string:
Starting with:
<span class="date">2009/07/06 15:54:12 GMT</span>
Using Javascript (with jQuery):
var dates = $("span.date", context);
// use for loop instead of .each() for speed
for(var i=0,len=dates.length; i < len; i++) {
// parse the date
var d = new Date(dates.eq(i).text());
// set the text to the localized string
dates.eq(i).text(d.toLocaleString());
}
From a practical point of view, it makes the text "flash" to the new value when the Javascript runs, and I don't like it.
From a principles point of view, I don't get why we need to do this - the browser should be able to localize standard things like currency, dates, numbers, as long as we mark it up as such.
A follow up question: Why do browsers/the Web not have such a simple feature - take a standard data item, and format it according to the client's settings?

I use toLocaleString() on my site, and I've never had a problem with the speed of it. How are you getting the server date into the Date object? Parsing?
I add a comment node right before I display the date as the server sees it. Inside the comment node is the date/time of that post as the number of milliseconds since epoch. In Rails, for example:
<!--<%= post.created_at.to_i * 1000 %>-->
If they have JS enabled, I use jQuery to grab those nodes, get the value of the comment, then:
var date = new Date();
date.setTime(msFromEpoch);
// output date.toLocaleString()
If they don't have JS enabled, they can feel free to do the conversion in their head.
If you're trying to parse the ISO time, that may be the cause of your slowness. Also, how many dates are we talking?

Unfortunately, there is not.
HTML & CSS are strictly used for presentation, as such, there is no "smarts" built in to change the way things are displayed.
Your best bet would be to use a server side language (like .NET, Python, etc.) to emit the dates into the HTML in the format you want them shown to your user.

It is not possible to do this with HTML, it has no smart tags that can make any kind of decisions like this. It is strictly presentational. I do wonder, though, if HTML5 perhaps has a tag for something like this...
Anyways, the way I see it, you have 3 options:
Stick to the Javascript way. There's questions with more details on it on this website, such as How do I display a date/time in the user’s locale format and time offset? and How can I determine a web user’s time zone?
Try to use geolocation. That is, your server side script fires off a request to one of the many geolocator services out there on the user's first page visit to try and guess where the user is. The downside of this is that it will be wrong about 10% of the time, so it's not that much better than the market share Javascript is going to get you.... (all in all, then, not a very good method...)
Ask the user! You will see that most websites that want to display a tailored experience for you will ask you this sort of thing because it's just not possible to know. As a neat fallback, you could wrap the question around <noscript> tags so you only ask those with Javascript disabled while offering the Javascript experience to those that have it.

Dojo has some pretty good localizations for dates and currencies. Using this method also allows you to pick different formats (e.g.: short date vs long date) and force locales.

The language and the user's locale should be sent on the HTTP header. You can use those to create the correct date format server-side to be displayed to the user. However, this is often undesirable because many users completely ignore their locale settings in their OS and/or browser. So, you may be feeding USA style timestamps to New Zealanders.
I liked the trick posted in the comment above, but it sounds like a QA headache, since you could be dealing with a large number of clients that implement timestamps in very different ways.
The most effective solution I have seen, is to simple provide a panel to allow your users to choose what time format they like. Some users even ****gasp**** like ISO formats. Then you do the time format conversion server side. If your application language does not have good locale to timezone formatting mapping, check your database. Many databases provide locale-based customized timezone formatting as well.

Because this anwser still popups in google I share that this is now possible to do by using a readonly datetime-local input (see below) and you can then style the input the way you want:
<input type="datetime-local" value="2018-06-12T19:30" readonly />
For more information see: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local