I need to display today's sunrise and sunset at Easter Island in local Easter Island time. I'm implementing it to the sidebar at http://www.easterislandtraveling.com/easter-island/
I noticed the EarthTools (http://www.earthtools.org/webservices.htm#sun) only covers Europe and USA. Is there any other way?
Over at http://www.timeanddate.com/worldclock/astronomy.html?n=914 they have all the necessary data.
I was playing around some with the standard PHP functions date_sun_info(), date_sunrise() and date_sunset() but I couldn't get them to work well with the local timezone.
I found a website that offers the service I'm looking for:
http://www.happyzebra.com/widgets/sunrisesunset.php?city=Easter%20Island
Works great! Only differed 2 minutes on the sunrise compared to http://www.timeanddate.com/worldclock/city.html?n=914
Related
I run a Rails 5 app in Brazil. So the timezone is set to America/Sao_Paulo. Now I have the problem that inside this timezone there are some regions that have summer time (e.g. Sao Paulo) and some don't (e.g. Salvador). So even the regions are in the same timezone they have different local times.
I don't know if this is also the case in other regions of the world. How do I handle this if I want to convert a time to Salvador time? I can do it manually by adding or subtracting on hour based on the region timezone, but is there a better way?
UPDATE:
I found this article: https://blog.bigbinary.com/2017/07/18/rails-5-1-returns-unmapped-timezones-from-activesupport-timezone-country_zones.html
So I tried to set Time.zone = "America/Bahia" and it worked.
I don't know if this now is Ruby or RoR...
As the subject asks; do UNIX timestamps change in each timezone?
For example, if I sent a request to another email the other side of the world saying, "Send out an email when the time is 1397484936", would the other server's timestamp be 12 hours behind my own?
The definition of UNIX timestamp is time zone independent. The UNIX timestamp is the number of seconds (or milliseconds) elapsed since an absolute point in time, midnight of Jan 1 1970 in UTC time. (UTC is Greenwich Mean Time without Daylight Savings time adjustments.)
Regardless of your time zone, the UNIX timestamp represents a moment that is the same everywhere. Of course you can convert back and forth to a local time zone representation (time 1397484936 is such-and-such local time in New York, or some other local time in Djakarta) if you want.
The article at http://en.wikipedia.org/wiki/Unix_time is pretty impressive if you'd like a longer read.
Unix time is defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970. So the answer is no
Unix timestamps do not change accross timezones, they are created for the purpose of having a standard time across globe.
NOTE:-
Timestamps are calculated on the basis of current time in the computer thus do not rely on them until and unless you are very sure about the time settings in the participating machines.
Someone stated that "UTC is Greenwich Mean Time without Daylight Savings time adjustments." This is simply untrue. GMT does not have Dayllight Savings Time. GMT is measured in Greenwich, England (at the Naval Obeservatory) [0 longitude, but not 0 lattitude]. UTC is measured at the equator [0 longitude and 0 lattitude - which happens to lie in the ocean off the cost of Africa].
What difference does it make? It doesn't make a difference in terms of "what time of day is it?" It does, however, make a difference in terms of calculating a year. Now you'd think a year would be measured based upon the location of the center (the core) of the earth, right? When the earth's core is back in the same location it was ~365 days ago, it has been a year. It isn't measured that way. It is measured by a specific location on the earth getting back to the same location (relative to the sun) that it was ~365 days ago. But the period of a day and a year don't divide evenly. Once the earth is back to about where it was a year ago, the earth isn't facing the same direction it was last year, so that spot on the earth isn't facing the same direction it was a year ago. Being further north, Greenwich isn't going to get back to the same spot (relative to the sun) that it was last year at the same time that 0 Lat / 0 Long is. So if you base the definition on Greenwith vs. 0/0, you get a, albeit slightly, different answer to the question "how many days are in a year". To put it another way, when a given spot on the earth gets back to where it was a year ago (relative to the Sun), the core of the earth isn't in the same spot it was a year ago, so what spot you pick matters because the core of the earth is going to be in a different spot (relative to the sun) than it was one year ago, if you pick a different spot on the earth.
Neither UTC nor GMT have daylight savings time. Europe/London time, the timezone that Greenwich resides in, does. But GMT does not. GMT is, what Americans would call a "Standard Time" - i.e. without DST.
Getting back to the question, Epoch time doesn't technically have a timezone. It is based on a particular point in time, which just so happens to line up to an "even" UTC time (at the exact beginning of a year and a decade, etc.). If that concept doesn't fit well in your brain, and if it helps to think of Epoch time as being in UTC, go right ahead. You're in good company and in the grand scheme of things, it really doesn't matter. You ever see those law suits where somoene is awarded $1. It's kind of a "you're right, but it doesn't really matter" type of verdict. If someone sued you for saying Epoch time is in the UTC timezone, they would win $1. That wouldn't buy them a cup of coffee at any Starbucks in any timezone on the planet.
IF both computers are set up correctly with their clocks set for the correct timezone and UTC values, they should return the same value.
Of course that's a big IF. There's almost certain to be a difference of at least a second, more often minutes between the time reported by two computers. And many computers are set up to have incorrect timezone settings, and will report their local time when asked a timestamp rather than UTC.
And in that lies the difference between theory and practice. In theory it's all the same, in practice you should not rely on it.
No, epoch timestamp should not change, because it has a fixed timezone which is UTC.
If you want to use a time object in other time zone, just look it up in libraries of the language you use, but do NOT try to add/substract a couple of hours from epoch timestamp and assume it's in another time zone, which will make things very confusing to other people, especially when you expose it in your API.
If you use C++, I recommend this library. I heard it will soon be added into standard library.
For all, I understand sometimes time object is hard to deal with and it looks easier to add/substruct on epoch timestamp. Please don't do it and do not persuade others to do it. A time object is much easier once you get used to it and can take care of time zone conversion easily without messing up with historical time zone changes due to politics/law etc...
The article here:
http://msdn.microsoft.com/en-us/library/exchange/bb738399(v=exchg.80).aspx
in the section "Use Registry Key Names for TimeZoneNames", tells me that when I can create a calendar item in Exchange, I can pass it the name of a timezone. This is sort-of working, but how do I name "Eastern Daylight Time"?
Only 'US Eastern Standard Time' is accepted as valid. In works in that I schedule something for say 14:00, when it displays in my Google calendar I see it is displaying at 15:00 EDT, so it used the EST timezone I passed in. Problem is that it sends out reminder emails with the time displayed in "US Eastern Standard Time".
When: Friday, August 30, 2013 2:00 PM-3:00 PM. US Eastern Standard Time
... rest of email ...
I don't want that text like that. It should say "US Eastern Daylight Time" or something like that.
The soap request contains XML like:
<t:CalendarItem xmlns="http://schemas.microsoft.com/exchange/services/2006/types">
...
<Start>2013-08-30T14:00:00</Start>
<t:MeetingTimeZone TimeZoneName="US Eastern Standard Time"></t:MeetingTimeZone>
<t:CalendarItem>
This is Exchange Server 2007, SP1.
Here is an image of what the email looks like, in Gmail. (The times are bit different from my above example, sorry). The appointment time is correct, but it in the email body it calls it "Eastern Standard Time", which is not right -- it should be "Eastern Daylight Time" or something like that. (Note that line is part of the email body generated by the Exchange Server, it is not something made up by Gmail.)
The Windows Time Zone key you're looking for is exactly: "Eastern Standard Time". This covers the US Eastern time zone, inclusive of both Eastern Standard Time and Eastern Daylight Time. It has a display name of "(UTC-05:00) Eastern Time (US & Canada)".
This is actually one of the examples I call out in the timezone tag wiki - which you should read if you haven't already.
The other key you found "US Eastern Standard Time" is actually for the zone with the display name of "(UTC-05:00) Indiana (East)" - which is segregated for historical reasons and is now obsolete. (See the Wikipedia entry on Time in Indiana, and Microsoft's KB article on this if you are interested in why.)
If you look in the Windows Registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones, you will see the valid keys. In each key, you will see the Display name that corresponds to each. This explains how they appear when you change your time zone in Windows.
With regards to Exchange Web Services, in the article you mentioned, it does talk about how you can use the key name. But it also talks about how you can pass much more information in the MeetingTimeZone element and use a display name instead.
If interoperability with Google Calendar (and others) is important, you might consider passing the IANA time zone name in the TimeZoneName attribute - in this case it would be America/New_York. You would still need to provide the <BaseOffset>, <Standard>, and <Daylight> elements, so that it will work right on Windows. See the MeetingTimeZone section in that article.
I should state that I haven't tried this approach myself, but it appears from the documentation that if you provide those elements that the TimeZoneName becomes less important to Windows but would still get passed along.
You should certainly be able to pass it using Microsoft's approach:
<MeetingTimeZone TimeZoneName="(GMT-05:00) Eastern Time (US & Canada)">
<BaseOffset>P0DT5H0M0.0S</BaseOffset>
<Standard>
<Offset>P0DT0H0M0.0S</Offset>
<RelativeYearlyRecurrence>
<DaysOfWeek>Sunday</DaysOfWeek>
<DayOfWeekIndex>First</DayOfWeekIndex>
<Month>November</Month>
</RelativeYearlyRecurrence>
<Time>02:00:00.0000000</Time>
</Standard>
<Daylight>
<Offset>-P0DT1H0M0.0S</Offset>
<RelativeYearlyRecurrence>
<DaysOfWeek>Sunday</DaysOfWeek>
<DayOfWeekIndex>Second</DayOfWeekIndex>
<Month>March</Month>
</RelativeYearlyRecurrence>
<Time>02:00:00.0000000</Time>
</Daylight>
</MeetingTimeZone>
What I'm suggesting is that you tweak it slightly by passing the IANA zone name instead and see if it behaves properly with Gmail and Google Calendar:
<MeetingTimeZone TimeZoneName="America/New_York">
<BaseOffset>P0DT5H0M0.0S</BaseOffset>
<Standard>
<Offset>P0DT0H0M0.0S</Offset>
<RelativeYearlyRecurrence>
<DaysOfWeek>Sunday</DaysOfWeek>
<DayOfWeekIndex>First</DayOfWeekIndex>
<Month>November</Month>
</RelativeYearlyRecurrence>
<Time>02:00:00.0000000</Time>
</Standard>
<Daylight>
<Offset>-P0DT1H0M0.0S</Offset>
<RelativeYearlyRecurrence>
<DaysOfWeek>Sunday</DaysOfWeek>
<DayOfWeekIndex>Second</DayOfWeekIndex>
<Month>March</Month>
</RelativeYearlyRecurrence>
<Time>02:00:00.0000000</Time>
</Daylight>
</MeetingTimeZone>
I've been creating kml files for a while now, using TimeStamps so that I can use the time scaling control. It used to be that times specified as UTC (with a 'Z' character at the end) would not be changed by Google Earth. They've apparently changed their approach and now adjust the UTC time to the local time of wherever a Placemark is located. For example:
<Placemark>
<name>1324</name>
<description>Local time: 13:50:12</description>
<Point>
<altitudeMode>relativeToGround</altitudeMode>
<coordinates>-79.344437,43.679943,0</coordinates>
</Point>
<TimeStamp><when>2012-09-26T13:50:12Z</when></TimeStamp>
</Placemark>
This location is set to 13:50:12 (1:50:12 PM), but will appear in the time slider control as 08:50:12, the "adjusted" local time for Toronto (North American Eastern Time Zone). I tried different formats for the timestamp:
<TimeStamp><when>2012-09-26T13:50:12Z</when></TimeStamp>
<TimeStamp><when>2012-09-26T13:50:12</when></TimeStamp>
<TimeStamp><when>2012-09-26T13:50:12+00:00</when></TimeStamp>
<TimeStamp><when>2012-09-26T13:50:12-00:00</when></TimeStamp>
And only specifying the offset (which I want to avoid) makes Google Earth give out the correct time:
<TimeStamp><when>2012-09-26T13:50:12-05:00</when></TimeStamp>
What is the format (if any) to tell Google Earth to ignore the timezone, to basically not adjust times?
Add-on: Working example at http://pastebin.com/DahChjsT, save as .kml and open.
Using latest version of free Google Earth, 7.0.1.8244 (beta)
I assume you are talking about the desktop version of Google Earth and not the web based API. That being said, if you make the time stamps with the normal Z notation, the time slider bar will appear and if you click the wrench on the slider it brings up the time options and you can select UTC as the time you want to use. This seems to stick when closing and re-opening the program. Hope that helps.
I'm building an application which will be able to send emails at any specific local time to any place in the world.
For example, my daily schedule (localtime):
8:00 AM - Send email to John in Toronto, Canada
9:15 AM Western Standard Time (Australia) - Send email to Bob in Perth, Australia
10:12 PM - Send email to Anas in Rabat, Morocco
I want to be able to execute this code on and Amazon EC2 server in a single location (e.g. São Paulo, Brasil).
I also know that Toronto is in Eastern Standard Time, (UTC - 5h) , but from March 11, 2012 to November 4, 2012, it is in Eastern Daylight Time (UTC - 4h).
I also know that Perth is in Western Standard Time (UTC + 8h), with no daylight savings.
I also know that Rabat is in Western European Time (UTC), but from April 29,2012 to July 20,2012, and August 19,2012 to Sept 30, 2012 it is in in West European Summer Time (UTC + 1h)
To keep track of these combinations of time zone, daylight savings, et cetera, I will, of course insist that all internal server times be in UTC. However, I need some way to keep track of when and how each time-zone jurisdiction switches time zones because of Daylight Savings or (in the case of Rabat) Ramadan, and then adjust my crontabs to accommodate these changes.
Is there an authoritative web service or set of tables somewhere which would help me keep these timezone changes in sync with my desire to deliver emails at the same local time every day to users in different time zones with different switchover dates for daylight savings?
Most programming languages give you access to timezone conversion functions. The most rudimentary ones only work between UTC and the "local" timezone of the server, so you will need a full-featured one, such as pytz for Python that will let you specify a local time with a timezone name (e.g. "America/Toronto") and convert it to UTC for you. Given that, you don't need to worry about the UTC offsets of different timezones (including historical offsets if they've changed) nor DST start end end times: the library will take care of it for you. Just make sure you have the latest database, which comes in the tzdata package.
As for your crontab, you're probably best off if the local timezone on the server that runs cron is UTC, that way you can put UTC times directly in the crontab. On the other hand, depending on the volume of events that you have, I would advice just having cron run your code at regular schedules intervals (such as every 5 minutes) and then your code figures out what events need to be triggered based on the current UTC time and the contents of your database. Then it doesn't matter what the timezone of the server is.
Is there an authoritative web service or set of tables somewhere ...
No, there is nothing "authoritative", but there is something close. It's called the TZ database, and it is currently under the oversight of IANA. Its home page is here.
It is also known as tzdata, zoneinfo, timezonedb, tzdb, the Olson Database, or the IANA Time Zone Database.
There are implementations for just about every language and platform you can imagine. You can read more in the tz-link file from the tzdb, and in the timezone tag wiki, here on StackOverflow.