Time zones in php work like this https://www.gsp.com/support/virtual/admin/unix/tz/gmt/
and when it named Etc/GMT+11 it actually GMT-11
and when it named Etc/GMT-11 it actually GMT+11
Why? And what does it mean Etc/GMT?
I find it in PHP, is it a bug in PHP or is it everywhere?
This is not a bug. The tz database identifiers of the form Etc/GMT±* deliberately have an inverted sign than the usual forms we expect under ISO 8601. That is, they are in terms of positive values being West of GMT, rather than positive values being East of GMT.
The reason is for backwards compatibility with POSIX style time zone identifiers, such as are used with the first format of the TZ environment variable. When POSIX compliant systems interpret this variable, values like America/Los_Angeles would clearly fall through to the third format (described in the same document), but values like Etc/GMT+11 are ambiguous as to which format rules should apply. Thus the zone identifiers must have their signs inverted to be compliant.
From the tz database where these zones are defined:
# Be consistent with POSIX TZ settings in the Zone names,
# even though this is the opposite of what many people expect.
# POSIX has positive signs west of Greenwich, but many people expect
# positive signs east of Greenwich. For example, TZ='Etc/GMT+4' uses
# the abbreviation "-04" and corresponds to 4 hours behind UT
# (i.e. west of Greenwich) even though many people would expect it to
# mean 4 hours ahead of UT (i.e. east of Greenwich).
This is also discussed in the Wikipedia article on the tz database.
As far as practical matters, the tz database commentary also says:
# These entries are mostly present for historical reasons, so that
# people in areas not otherwise covered by the tz files could "zic -l"
# to a time zone that was right for their area. These days, the
# tz files cover almost all the inhabited world, and the only practical
# need now for the entries that are not on UTC are for ships at sea
# that cannot use POSIX TZ settings.
So, if you're not keeping time for ships at sea, I highly suggest you use a locality based identifier instead. (perhaps Australia/Melbourne ?)
Also, A better source of time zone identifiers would be the one on Wikipedia.
Since you said you were using PHP note that the PHP documentation has a list as well, and on the "Others" page, it actually explains this as well:
Warning
Please do not use any of the timezones listed here (besides UTC), they only exist for backward compatible reasons, and may expose erroneous behavior.
Warning
If you disregard the above warning, please also note that the IANA timezone database that provides PHP's timezone support uses POSIX style signs, which results in the Etc/GMT+n and Etc/GMT-n time zones being reversed from common usage.
For example, the time zone 8 hours ahead of GMT that is used in China and Western Australia (among other places) is actually Etc/GMT-8 in this database, not Etc/GMT+8 as you would normally expect.
Once again, it is strongly recommended that you use the correct time zone for your location, such as Asia/Shanghai or Australia/Perth for the above examples.
Related
Given rails has a convention for most common tasks, is there a format of date/time data that ruby/rails ingests most easily, or which it 'prefers'?
I will have date/time data coming from an external source, and I can choose how it's formatted (but it not be easy to change later). I have researched and found two recommended formats:
A string of format YYYY-MM-DD HH:MM:SS
Unix epoch time (i.e. number of seconds since 1 Jan 1970)
Does rails deal more easily with one of these formats over the other (or is there another convention?)
Additional note: I can see from this talk that it's almost always best to store time in UTC, so I have that much figured out
I would agree that Ruby on Rails default to using the UTC time zone at least in the database.
I do not see a strong convention what time string format Rails prefers, but I would always choose ISO 8601: 'YYYY-MM-DDTHH:MM:SSZ'
Is there a list with complete information about caracteristics like:
currency
date and time (including if it is 12 or 24 hours) format
measurement units (distance, speed, temperature...)
preferred language
masks for phone and local documents
timezones (at least the main ones / variations if daylight saving time is applicable)
decimal and thousand separators
for countries around the world?
I am doing it myself, however, as it takes too long to gather the data, I tought maybe someone have already have it done.
Don't reinvent the wheel.
Start with CLDR, the Common Locale Data Repository (http://cldr.unicode.org/)
Or if you want to honor the locale preferences in your application, use standard I18N APIs (from you platform, whatever that is, or a popular library, like ICU, http://site.icu-project.org/)
For currencies you can rely on international standard ISO 4217. It also refers to the country code of each currency code. This website provides this dataset for download.
For date formats, the best reference seems to be wikipedia.
The measurement units is a very complex domain, because you need to know which dimension you measure (speed, distance, volume, ...) and the units (paper size in cm is not the same as road distance in km). Here you have some lists per type of units, but not per country. This website shows a list of system of measurements in use per country. You'll see that fortunately ùany of them share the metric system, so taht you could use an approach "by exception" documenting yourself only on the remaining ones".
For languages, you have international standard ISO 639 or IANA , but it's country independent. You can look at reference lists for locale such as here: it associates a language code to a country code, so that you could complete the standard information. Note that some countries have several language, and you cannot and should not decide which one is preferred.
For telephone masks, there is only an international list of prefix. The usage vary greately accross countries. Some have fixed format, some use variable formats, some have zone prefixes and some not. Sometimes there is even no clear standard in the country and there are several coexisting usages. I'm not aware of any global list of these.
For timezones around the world, you could have a look at IANA which is extremely comprehensive.
For decimal and thousand separators, it's not an international standard. Again I'd suggest to refer to Wikipedia
I need to map IANA/Olson timezone id to abbreviations, like EST, PST, etc.
I understand that this is not 1-to-1 mapping and that, for example, for EST there are quite a bunch of IANA timezones.
Is there some kind of database/mapping I can use for this?
PS: JavaScript solution is preferable, but any info that could help me to build this mapping (IANA timezone id -> abbreviation) is appreciated.
The IANA TZDB source data does have abbreviations already, but they have to be computed for the date in question. You can see it in the example data here, in the Zone.FORMAT and Rule.LETTER/S columns.
Since time zone abbreviations like CST can be ambiguous, it is only recommended you use them for display to a human. Never attempt to use them going the other direction, because only a few will be recognized by most implementations, and they tend to be valid only for the USA.
Since you asked for code that could do this for you, look at the bottom half of the code in my answer of how to do this using Noda Time in .Net. (The top half is about translating from a Windows zone to an IANA zone first, which you don't need.)
You could look at one of the several TZDB libraries for JavaScript, but I'm not sure if any directly expose the abbreviation data or not. Besides, that's a bit heavy for something so small.
In java with joda-time, we can get time-zone abbreviation from iana id as below
DateTimeZone dz = DateTimeZone.forID("America/New_York");
String tzid = dz.getShortName(DateTimeUtils.currentTimeMillis());
//tzid will be 'EST'
String longerTimeZoneName = dz.getName(DateTimeUtils.currentTimeMillis());
//longerTimeZoneName will be 'Eastern Standard Time'
I am building apps that support users spread across multiple countries / time zones. I had two questions with timezone manipulations in xpages. Please share any tips you have to make this easier to code and maintain.
Time zone list
In notes client and traditional domino web design we have a standard timezone control that lists exhaustive timezone options. With xpages, we do not have any such control and have to resort to maintaining some config based static list on our own. This is not very desirable as it does not update when DST rules change for countries or new time zones are introduced. These apps may also be accessed via notes client so we cannot really use java tz format, it should be the notes TZ constant (Z=6$DO..).
Is there a way to show a dynamic list of notes timezone options?
Time zone conversion (notes/java)
How do you convert a notes timezone constant into its java equivalent and vice-versa?
Scenario:
If a user in North America wants to know the current time in a different timezone, say X. Where X is stored in the current notes document. Can you do this conversion using SSJS code?
Currently, we are using #Texttotimeinzone and evaluating it (#Texttotimeinzone is not a SSJS function). Is there a simpler way to convert a notes tz constant to java so we can perform all date conversions using java classes?
The teamroom template that ships with the ExtLib has a calendar that has the option to create a meeting and specify the time zone.
check out the custom control "controlSectionTimezonePicker". It might not be exactly what your looking for but should be a good start as a working example.
You can include the time zone information along with the date.
Initialise the date variable and use .toString() (link to documentation)
Or you can compute it in a field with JS like
var d=new Date();
d.toString()
Instead of .toString(), you can use .toUTCString().
I have a shell script (zsh, to be precise) which uses
strftime "%I:%M %p %Z (%a, %b %d)" "$EPOCHSECONDS"
to generate a "current time" such as
"02:45 PM CST (Thu, Mar 01)"
This needs to be able to display the time in several different USA timezones, and so I have been using 'US/Eastern', 'US/Central', and 'US/Pacific' like so:
export TZ='US/Eastern'
strftime "%I:%M %p %Z (%a, %b %d)" "$EPOCHSECONDS"
That seems to work just fine, and I prefer it to using TZ='America/CityName' because it doesn't require me to know which city is in which TZ, I just need to tell it which TZ I want.
However, I happened across http://www.php.net/manual/en/timezones.others.php and saw that it says
Please do not use any of the timezones listed here (besides UTC),
they only exist for backward compatible reasons.
I don't know what the issues are with the US/Region names, but I'm curious to know if using them is likely to cause a problem in the foreseeable future, or are they still safe to use? Is it just PHP which doesn't like them, or is everyone moving away from them?
The standard format for naming timezones in the Olson database is Continent/City. The "old" names you mention like US/Eastern, US/Central, and many more, are listed as backward compatibility links in the tzdata source distribution (in the file "backward"). According to the comment at the top of the file, these names may have become backward compatibility links in late 1993.
I think I remember reading that this standard was adopted because it was felt to be more stable: geopolitical (country) boundaries change, cities never move around. Maybe also because names like "Eastern" and "Central" are thought to be more confusing because they mean different timezones in different parts of the world. However, I cannot find any references to the naming rationale at the moment, so don't quote me on this.
The Continent/City-style names are preferred. Notice that operating systems like Debian and Ubuntu ask you to select the system timezone using these names (unless they autodetect it at installation time), Using these names you wouldn't really be required to, as you say, "know which city is in which TZ" because the city name is, well, part of the timezone name! So if you happen to have learned the Continent/City names instead of or in addition to the Country/Region names, you're already OK.
That being said, I do not think that these names will ever disappear. On the timezone mailing list, they are definitely always called "backward compatibility", not "deprecated", and are intended to stay, notwithstanding what PHP recommends.