Is there a way in Elixir or Erlang to print out the name of current timezone? I know that I can get the local time in Elixir by calling the Erlang Calendar module.
:calendar.local_time
and I can get the current time in UTC in Elixir by using the Calendar package:
Calendar.DateTime.now_utc()
However, neither of these packages provide me with a method that will return the name of the current time zone. I would like to store my dates in UTC but display them in the local time zone. Where I live, the current timezone is called "MST7MDT" (and "MST" when DST is not in effect) but I don't want to hard code those strings into my program.
Is there a way to have Elixir tell me that my current timezone is "MST7MDT", so I can then use the Calendar.DateTime functions to format my DateTimes correctly?
I think the best approach would be to just use :calendar.universal_time_to_local_time when displaying the dates to your end user.
But if you really need to get the current time zone of the system, and it's a Unix-like system, you can always do something like:
def get_timezone() do
{zone, result} = System.cmd("date", ["+%Z"])
if result == 0, do: String.trim(zone)
end
Not the most elegant solution, but works. There doesn't seem to be anything equivalent to java.util.TimeZone.getDefault() available.
I don't think there is actually the official way how to get local timezone information as a string in erlang, but you may try qdate library
Related
I have an ISO-8601 datetime stamp, and need to convert it into local time in GMT. What is the way to do it in Ruby on Rails? I have '1325233011', and need to convert it into local time in GMT standards.
I think what you're asking for is a locale time in GMT+5.
Given an ISO timestamp, 1325233011
When I convert this to a locale-based date/time
Time.at(1325233011) => '2011-12-30 03:16:51 -0500'
Take a look at the ruby-docs, http://www.ruby-doc.org/core-1.9.3/Time.html for more information. Ruby has robust Time and Date classes with many helper utilities. My machine is configured for GMT-5 so it returns the local time. It's easy to change the way timezone settings are interpreted in your program, but that's for another day. Hope this helps!
From Collegue's help got it
Time.at(1325233011).to_datetime
For Iso-8601:
Time.at(1325233011).to_datetime.iso8601
For verification of time correct conversion and comparision use this link
http://coderstoolbox.net/unixtimestamp/
Can anyone kindly enlighten me on how to get previous day's date in 'YYYY-MM-DD' format using Lua?
I.E., a snippet that will return the date of the previous day from the day during which it is run.
Try
print(os.date("%Y-%m-%d",os.time()-24*60*60))
Strictly speaking this is only guaranteed to work on a POSIX system, but it probably works in most systems.
There is a library LuaDate which can be very helpful for Date Manipulations
http://luaforge.net/projects/date/
It is very easy to use, since it is documented well!
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.
I have an application which save datetime using Time.now, but when I retrieves it and compare with Time.now again it not the same format and result in unexpected result.
What should I do to always make this time standard all the time.
Thanks,
Rails treats time in a special way because time zone support in Ruby was deemed insufficient, i.e. Ruby Time instances only work with UTC and ENV['TZ'] A Time object persisted in ActiveRecord will therefore look quite different to the return value of Time.now. To get on the same page as Rails use Time.zone.now
Favorite thing ever when it comes to time parsing and standardizing values is the Chronic gem. Natural format time parser. Very handy. Saves me from a lot of work trying to write/read time formats correctly for databasing time formats. Maybe not really the solution to the problem, but its worth a look.