As many of you know, Russia has eleven time zones, and has (or will) cut two of them. It is possible that they may end daylight savings time altogether.
Does anyone know if they have cut two time zones, and if daylight savings is now a thing of the past? If so, does daylight savings end in all time zones, or just some?
I maintain some software that may need to be patched and can't find two news sites that agree on if they have, or have not implemented these changes.
My biggest concern is daylight savings.
According to wiki article,
On February 8th 2011, Russian
President Dmitry Medvedev issued a
decree cancelling DST in Russia. Under
the decree, all clocks in Russia will
advance one hour on March 27th 2011
but will not change back the following
October, effectively making Moscow
Time UTC+4 permanently.1
According to Wikipedia:
On March 28, 2010, the following changes were introduced, which, in particular, led to abolition of two of the eleven time zones.
* The Udmurt Republic and Samara Oblast started using Moscow Time, thus eliminating Samara Time.[2][3]
* Kemerovo Oblast started using Omsk Time.[4]
* Chukotka Autonomous Okrug and Kamchatka Krai started using Magadan Time, thus eliminating Kamchatka Time.[5]
There is no mention of daylight savings being canceled, only that its abolition was proposed.
Related
I am using Rails 5 and my app's timezone is set to Brasilia.
Right now it's winter (no daylight saving) in Brazil so
Time.current.dst? returns false
But in Brazil daylight savings starts at 21/10/2018, so when I do
(Time.current + 10.days).dst? I expect it ti return true, but it returns false.
Is there a table where I can check what dates Rails considers for start end and of daylight savings in each timezone?
Or as another example. I understand that UTC does not have daylight savings. So
Time.current.strftime(%Z) return -3 which is the correct diference between UTC and current Brazil time.
But when I do
(Time.current+10.days).strftime(%Z) is still returns -3 but that date is after Brazil has changed time, so it should be -2. Something seems to be wrong.
Per the Rails documentation:
The TimeZone class serves as a wrapper around TZInfo::Timezone instances.
TZInfo::Timezone instances are provided via the Ruby TZInfo gem. The data for TZInfo is provided in a separate TZInfo-Data package. Staying current with that will keep your time zone data accurate. This data is sourced from the IANA time zone database (TZDB), as it is with most other programming languages.
Note that it is generally preferable to use the IANA time zone identifiers with tzinfo gem directly, as Rails time zones are limited to "a meaningful subset of 134 zones" (per the same docs), but contain many duplications and omissions, and provide no criteria as to what "meaningful" means. More on this in the timezone tag wiki (near the end).
Also, Brazil starts DST on November 4th in 2018, not on October 21st. See here and here. This change was reflected in IANA TZDB 2018a, which was reflected in TZInfo-Data v1.2018.1. If you have that version or newer, then you have the newer, correct Brazil DST date, and thus explains your results.
There was recently a plan to push Brazil's DST date out even further to November 18th, but the government retracted that plan before it ever became official, and thus was never represented in the time zone data.
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...
I have a doubt regarding daylight savings time applicable to the North American region time zones:
The scenario is:
I have to work between lets say the following time zones: Eastern Time (UTC-5.00) and Mountain Time (UTC - 7:00).
Generally the daylight savings time adjustment of +1 hour will be applicable from 2nd Sunday of March for the said time zones.
Case 1: Initially the time zones are 2 hours apart
Case 2: On 10th March 2013 (2nd Sunday of March this year) exactly after the time 1:59:59 AM, the time will be 3:00 AM (because of daylight savings time adjustment) hence for the next 2 hours these time zones (Eastern and Mountain) will be 3 hours apart.
What I am doing:
I create a file in a machine X (under Eastern Time) and then I send this file to a different machine Y (under Mountain Time). This transfer operation consumes negligible time. After the file is received at Y. The creation time of the file is read (which will obviously give the Eastern Time) and then this time is converted to the Mountain Time with the help of ConvertTime method of TimeZoneInfo class and the result is stored in DB. This works just perfect.
What is my concern:
When I create a file during such a time when daylight savings time adjustment is applicable for the Eastern Time and not for the Mountain Time (Read Case 2 above), will I still be getting the correct Mountain Time equivalent for the specific Eastern Time with the same ConvertTime method of TimeZoneInfo class or is there anything else that I need to take care of?.
Hope I made myself clear, if not please do ask.
Seeking for a explanation to my doubt :)
Regards,
Vikas
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.
I finally found out the difference between UTC and GMT by making the effort to look it up on Wikipedia today. Technically speaking it appears that GMT != UTC because you do not know if it is UTC or UT1 being referred to. However practically, people use the terms interchangeably to indicate the same timezone.
A while ago, I suggested that we change the user interface of one of my companies apps to display UTC instead of GMT.
Just to be sure that our database was not calculating the potential seconds difference between GMT and UTC, I ran the below query and verified that they both are just acting as aliases for the same timezone.
select now() AT TIME ZONE 'GMT', now() AT TIME ZONE 'UTC';
timezone | timezone
----------------------------+----------------------------
2009-02-11 08:46:11.643032 | 2009-02-11 08:46:11.643032
(1 row)
What do you think? Do enough users out there understand UTC? Is it better to use the older but more common term? Or should I just do a UTC/GMT?
Normal humans don't need to worry about the few seconds difference between GMT and UTC. The difference only matters to astronomers and time nerds.
I have seen very little software that bothers to make the distinction. Most software ends up using the labels "GMT" and "UTC" interchangeably. Typically it just means "clock time after removing the local time zone offset in exact hours (or half/quarter hours)."
In most cases, nobody will be concerned about the sub-second technical difference between GMT and UTC.
However, writing that the time is expressed in UTC instead of GMT avoids one source of confusion:
Greenwich (and the UK in general) is currently GMT+01:00 because of the daylight saving time (DST).
GMT+01:00 does not mean 1 hour ahead of the time in the UK as one could mistakenly think. Because of the DST, GMT+01:00 is currently the exact time in England.
Stating it as UTC+01:00 helps to avoid this confusion.
Personally, I think of the term UTC before I think of GMT.
I think of GMT before UTC, but I am also living at GMT (+/-0)