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.
Related
I trying to parse a date in ISO 8601 format and some moments aren't clear for me.
For example, I have the next date: 2020-04-16T07:16:34.858215+03:00 in Europe/Moscow timezone.
Does it mean 07:16 in Moscow time or 10:16? I mean do I need to add 3 hours to date or date is in Moscow time already and timezone just shows how it diffs from UTC?
P.S. I tried to find information about it but everywhere is just common format description without details.
The time specified is the local time, so 2020-04-16T07:16:34.858215+03:00 means 7:16am in Moscow, or 4:16am UTC.
Wikipedia has a good example which clarifies things to at least some extent:
The following times all refer to the same moment: "18:30Z", "22:30+04", "1130−0700", and "15:00−03:30". Nautical time zone letters are not used with the exception of Z. To calculate UTC time one has to subtract the offset from the local time, e.g. for "15:00−03:30" do 15:00 − (−03:30) to get 18:30 UTC.
It's really unfortunate that ISO-8601 talks about this as a time zone, when it's only a UTC offset - it definitely doesn't specify the actual time zone. (So you can't tell what the local time will be one minute later, for example.)
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.
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 live in a country where they change the time twice a year. That is: there is a period in the year when the offset from UTC is -3 hours (-180 mins) and other period where the offset is -4 hours (-240 mins)
Grafically:
|------- (offset = -3) -------|------- (offset is -4) -------|
start of year mid end of year
My question is:
the "timezone" is just the number representing the offset? that is: my country has two timezones? or the timezone includes this information?
This is important because I save every date in UTC timezone (offset = 0) in my database.
Should I, instead, be saving the dates with local timezone and saving their offset (at the moment of saving) too?
Here is an example of a problem I see by saving the dates with timezone UTC:
Lets say I have a system where people send messages.
I want to have a statistics section where I plot "messages sent v/s hour" (ie: "Messages sent by hour in a regular day")
Lets say there are just two messages in the whole database:
Message 1, sent in march 1, at UTC time 5 pm (local time 2 pm)
Message 2, sent in august 1, at UTC time 5 pm (local time 1 pm)
Then, if I create the plot on august 2, converting those UTC dates to local would give me: "2 messages where sent at 1 pm", which is erratic information!
From the timezone tag wiki here on StackOverflow:
TimeZone != Offset
A time zone can not be represented solely by an offset from UTC. Many
time zones have more than one offset due to "daylight savings time" or
"summer time" rules. The dates that offsets change are also part of
the rules for the time zone, as are any historical offset changes.
Many software programs, libraries, and web services disregard this
important detail, and erroneously call the standard or current offset
the "zone". This can lead to confusion, and misuse of the data. Please
use the correct terminology whenever possible.
There are two commonly used database, the Microsoft Windows time zone db, and the IANA/Olson time zone db. See the wiki for more detail.
Your specific questions:
the "timezone" is just the number representing the offset? that is: my country has two timezones? or the timezone includes this information?
You have one "time zone". It includes two "offsets".
Should I, instead, be saving the dates with local timezone and saving their offset (at the moment of saving) too?
If you are recording the precise moment an event occurred or will occur, then you should store the offset of that particular time with it. In .Net and SQL Server, this is represented using a DateTimeOffset. There are similar datatypes in other platforms. It only contains the offset information - not the time zone that the offset originated from. Commonly, it is serialized in ISO8601 format, such as:
2013-05-09T13:29:00-04:00
If you might need to edit that time, then you cannot just store the offset. Somewhere in your system, you also need to have the time zone identifier. Otherwise, you have no way to determine what the new offset should be after the edit is made. If you desire, you can store this with the value itself. Some platforms have objects for exactly this purpose - such as ZonedDateTime in NodaTime. Example:
2013-05-09T13:29:00-04:00 America/New_York
Even when storing the zone id, you still need to record the offset. This is to resolve ambiguity during a "fall-back" transition from a daylight offset to a standard offset.
Alternatively, you could store the time at UTC with the time zone name:
2013-05-09T17:29:00Z America/New_York
This would work just as well, but you'd have to apply the time zone before displaying the value to anyone. TIMESTAMP WITH TIME ZONE in Oracle and PostgreSQL work this way.
You can read more about this in this post, while .Net focused - the idea is applicable to other platforms as well. The example problem you gave is what I call "maintaining the perspective of the observer" - which is discussed in the same article.
that is: my country has two timezones? or the timezone includes this information?
The term "timezone" usually includes that information. For example, in Java, "TimeZone represents a time zone offset, and also figures out daylight savings" (link), and on Unix-like systems, the tz database contains DST information.
However, for a single timestamp, I think it's more common to give just a UTC offset than a complete time-zone identifier.
[…] in my database.
Naturally, you should consult your database's documentation, or at least indicate what database you're using, and what tools (e.g., what drivers, what languages) you're using to access it.
Here's an example of a very popular format for describing timezones (though not what Windows uses).
You can see that it's more than a simple offset. More along the lines of offsets and the set of rules (changing over time) for when to use which offset.
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)