I am pulling a date from a server in ISO 8601 format. The date represents the time a specific episode of a specific show airs. Here is an example date:
"2013-07-30T21:00:00-05:00"
That is July 30th, 2013 at 9:00PM EST. EST being -05:00. The problem comes in when I try and display the date back to the user(myself in this case). I am currently in central time but daylight savings time is active. Which means iOS says that I am currently in Central Daylight Time which is also -05:00(normal CST is -06:00).
This show airs in my CST time zone at 8:00PM. It doesn't matter if daylight savings time is on or off, the show always airs whenever the clock hits 8:00PM. Normally if I wasn't in daylight savings time iOS would be able to do the proper conversions as it would be moving from -05:00 to -06:00. SInce I am currently in daylight savings time though it sees -05:00 as the original offset and -05:00 as my current offset so it does no conversion and displays the show starting at 9:00PM. Any idea how to deal with this?
Unfortunately there is no way to map just a time zone offset like -05:00 back to an actual time zone like Central Time or Eastern Time. As you pointed out, it could be Central Daylight Time, or Eastern Standard Time. However, it could be any number of other time zones that happen to use a -05:00 offset at one point or another. See this list of time zones and sort by one of the offset columns so you can get an idea of how many their are. You can also look here.
Now fortunately, you have another piece of information - the date/time. So you can use this to partially distinguish between some of these zones. You also may be able to further limit the ambiguities if you know for certain that your data is the USA.
There is still one problem though. A time like 2013-11-03T01:00:00-05:00 is actually in both CDT and EST simultaneously! How can that be? Well, in the USA we do not all change our clocks at the same moment. Each time zone changes it at 2AM in their own local time. So there is one hour every year that Eastern time has already encountered their fall-back transition, but Central time hasn't yet.
The only real way to deal with all of this is to store some other bit of context information, such as the full IANA time zone (America/New_York for Eastern or America/Chicago for Central, etc.) - or if it's just for display then you can store a string with the time zone abbreviation of your choosing (EST, CDT, etc.).
See also: "Time Zone != Offset" in the timezone tag wiki.
Related
I'm working on a website interface and I see a drop down that says "Change your timezone". When I click on that drop down, I see a list like this:
CST - America/Costa Rica (GMT -06:00)
CST - America/El Salvador (GMT -06:00)
CST - America/Guatamala (GMT -06:00)
etc...
EDT - America/New York (GMT -04:00)
EDT - America/Nipigon (GMT -04:00)
EDT - America/Toronto (GMT -04:00)
etc...
I vaguely recall working with some PHP libraries and Javascript date libraries that also require you to specify location like America/Toronto and America/New York in addition to specifying the timezone (eg. GMT offset or UTC offset).
My question is why are locations like America/Toronto or America/New York required when working with timezones? Will there ever be multiple political jurisdictions in the same timezone that show different times?
This is the naming scheme of the tzdb. Their explanation:
Each main entry in the database represents a timezone for a set of civil-time clocks that have all agreed since 1970. Timezones are typically identified by continent or ocean and then by the name of the largest city within the region containing the clocks. For example, America/New_York represents most of the US eastern time zone; America/Phoenix represents most of Arizona, which uses mountain time without daylight saving time (DST); America/Detroit represents most of Michigan, which uses eastern time but with different DST rules in 1975; and other entries represent smaller regions like Starke County, Indiana, which switched from central to eastern time in 1991 and switched back in 2006.
Wikipedia has some discussion on the correspondence with national borders:
Country names are not used in this scheme, primarily because they would not be robust, owing to frequent political and boundary changes. The names of large cities tend to be more permanent. However, the database maintainers attempt to include at least one zone for every ISO 3166-1 alpha-2 country code, and a number of user interfaces to the database take advantage of this. Additionally there is a desire to keep locations geographically compact so that any future time zone changes do not split locations into different time zones.
There have been some exceptions: the former countries of North Yemen and South Yemen were both covered by Asia/Aden, and East and West Germany were both covered by Europe/Berlin.
They can certainly cross sub-national boundaries. For instance the US states of Utah, New Mexico, Wyoming, Montana and Colorado (and parts of some others) are covered by America/Denver.
At least one thing is that some locations have daylight saving which changes UTC offset depending on time of year.
Properly time zone are regional zones with same time rules. If you want to go to past dates, you will find that New York and Toronto were using different times. So it it correct that time zone is a location string. If you remember when you installed a new computer, it ask the time zone (continent/city) and not a time offset.
Then you have Eastern (standard) time (EST). This is just an offset compared to GMT/UTC. Some US states may change the time (from one to the other, e.g. in boundary zones). Some states/countries may choose not to use EDT (daylight). But you keep the zone. For this reason it is better to use the notation: "time zone": geographic and possibly fix, "time offset" the difference of time compared to GMT at that time. (and this may changes because of daylight times, but also because political reasons). Usually we use "time offsets" for larger geographic entities, because it is easier to compare times (now but not for historical or future times).
But so. Time offset are well defined (not really: same letters may be used for different times, usually in different continents). Time zone requires a database which it should be updated regularly: rules changes.
At 6:00am Sydney time, Rory Allan clicks the foofoo button in their browser.
This inserts into the foofoo table with an 8:00pm UTC timestamp in the database of my server.
A lot of people are excited about this foofoo button, and they wanted to see what time of the day Sydney time Rory clicked it.
As I stare at my screen in California and view the status of the click, I want to see that he clicked it at 6:00am, not 1:00pm, which is what I will see if I pull the UTC time from the server and let my browser convert it.
You see, a lot of different people click foofoo, such as Phillip Herman in Germany, or Ivan Efimiov in Russia. And all we care about is the relative time of the day they clicked it, in the location they clicked it, regardless of the viewing location.
I don't know the best way to do this. Do I take the local timestamp and convert it to a string, storing it in addition to the real UTC timestamp? Or is this a common problem with a common resolution that I haven't found? I'm guessing / hoping the latter.
This isn't Language specific. These dates have a long journey:
Unix timestamp > Python date > JSON > Node > Mongo > Node > Browser
Ok, clearly 8:00pm UTC is not enough information. But what do you really want to know?
Is 06:00 enough information?
Look for time-only data types, preferably those that reflect time-of-day, rather than elapsed-time. These are often called LocalTime, TimeOfDay, etc.
Or, use strings in HH:MM format (on a 24-hour clock)
Or record the total number of minutes as an integer (60 * HH) + MM.
Or if you need a higher precision, then use seconds, or milliseconds, or microseconds, etc...
Is 06:00 Australia/Sydney enough information?
Store the time as mentioned earlier and store the time zone name in a separate string.
But be careful, because without a date you don't know if UTC+10 or UTC+11 was in effect.
Is 06:00+10:00 enough information?
You could look for a time with time zone data type, such as the one that exists in PostgreSQL, though even the PostgreSQL docs strongly discourage using this type.
Instead, store the time and offset as separate components.
Be careful, because you'd not necessarily know if this data was from Sydney. There are other time zones with UTC+10 at parts of the year too.
Assuming you have the date, such as today, then:
Is 2017-05-31T06:00 enough information?
Store the date and time together in a component that is sometimes called DateTime or LocalDateTime in various languages - but be careful that it is not bound to any specific time zone. Use DateTimeKind.Unspecified in .NET, or "naive" DateTime's in Python, etc.
For MongoDB and others that don't have such a type, use a string in ISO8601 format.
Be careful, because this time could come from anywhere in the world. Nothing here relates it to a specific point in time.
Is 2017-05-31T06:00+10:00 enough information?
Some languages and databases have a DateTimeOffset or OffsetDateTime type for this purpose.
If not, you can store a "Unix Timestamp" and also store the offset from UTC separately.
Or you can just store a string in ISO8601 format with the offset included - just be very careful with regard to comparisons / sorting.
Is 2017-05-31T06:00 Australia/Sydney enough information?
Store separately the date+time component from the time zone.
Consider that a time may be ambiguous during a DST fall-back transition.
Is 2017-05-31T06:00+10:00 Australia/Sydney enough information?
Here we have everything we might possibly need. Use a ZonedDateTime in Java/Joda-Time/Noda-Time, or an "aware" DateTime in Python (pytz, dateutils, etc.), or similar types when they exist in your platform.
Watch out for timestamp with time zone, as you might expect it to store the time zone and it typically does not (despite the name).
If not available, then consider storing a Unix timestamp and separate the time zone name as a string.
As you can tell - there are a LOT of options, and it really depends on exact use case and features available in each language/platform. You'll find more details if you search/ask for each one separately.
tl;dr
Exchange date-time values in UTC as strings in standard ISO 8601 format.
Work in UTC
General rule in date-time handling is to think in UTC, work in UTC, log in UTC, share in UTC, and store in UTC. But present in zoned time for the user.
By think in UTC, I mean every programmer needs to learn to stop their parochial thinking about their own particular home time zone. Translating back-and-forth to your own zone to UTC to other zones will drive a person nuts. Think of UTC as The One True Time®. All other zones and offsets are mere variations.
This strategy is much like internationalization. The programmer uses key strings in her own human language to look up string values from the localization tool to present a value (piece of text) in the human language preferred by her user. In date-time handling, the programmer works in UTC but applies a zone preferred by her user for presenting text in the user-interface.
Moment in UTC
The basic Java class for this Instant. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).
So when Rory in Sydney clicks his button, we record an Instant object.
Instant instant = Instant.now() ;
instant.toString(): 2017-06-01T09:24:54.435Z
Zoned
To present that moment to Rory in his own time zone, we apply a ZoneId to get a ZonedDateTime object.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "Australia/Sydney" ) ;
ZonedDateTime zdt = instant.atZone( z );
zdt.toString(): 2017-06-01T19:24:54.435+10:00[Australia/Sydney]
Now we have two objects, instant & zdt, that both refer to the same simultaneous moment on the timeline. The only difference is wall-clock time.
If the user in California wants to see the moment of Rory's button click according to Sydney time, then we already have that solution seen above. If not, if the California user wants to see the moment of Rory's button click in her own California clock, then read on.
We can adjust into yet another region’s wall-clock time by applying another time zone.
ZoneId zAmericaLosAngeles = ZoneId.of( "America/Los_Angeles" );
ZonedDateTime zdtAmericaLosAngeles = instant.atZone( zAmericaLosAngeles );
zdtAmericaLosAngeles.toString(): 2017-06-01T02:24:54.435-07:00[America/Los_Angeles]
Now we have three objects that all represent the same simultaneous moment: instant, zdt, and zdtAmericaLosAngeles. One moment, three wall-clock times.
See this above code run live at IdeOne.com.
Time-of-day
If you literally meant you want the time-of-day only, without the date, you can extract a LocalTime object from those objects above.
But think twice about doing this, as presenting a time-only without date and zone can lead to ambiguity and misunderstanding.
LocalTime lt = zdt.toLocalTime();
all we care about is the relative time of the day they clicked it, in the location they clicked it, regardless of the viewing location
If you are really really really sure that is what you want, then combine my advice above. (But I doubt this is a wise way to go.)
LocalTime lt = LocalTime.now( ZoneId.of( "Australia/Sydney" ) ) ; // Current time-of-day in Sydney.
Library for date-time
We have been using the modern java.time classes in examples above. They are exceptional – I mean than literally. They are virtually unique. Virtually all other platforms have terrible support for date-time work. The predecessor to java.time was the Joda-Time project which was ported to .Net platform as Noda Time. Other than java.time & Noda Time, I know of no other decent library on other platforms.
ISO 8601
The ISO 8601 standard defines many sensible practical formats for textual representation of date-time values.
The java.time classes use the standard formats by default when generating & parsing strings. You have been viewing those ISO 8601 formats in examples above. Except for ZonedDateTime which wisely extends the standard by appending the name of the time zone in square brackets.
The T in the middle separates the date portion from the time-of-day portion.
For UTC, the Z on the end is short for Zulu and means UTC.
For offset-from-UTC, you see a plus/minus number of hours and minutes ahead of or behind UTC. A time zone is history of past, present, and future offsets in use by a particular region.
Database
How databases handle date-times varies widely, though poor support is most common. A database driver, such as JDBC drivers, add another layer of behavior. So no way to succinctly address that here. And this topic is already asked and answered in many other pages in Stack Overflow.
If your database lacks serious date-time support, you may be better off storing the ISO 8601 strings with the Z on the end. These values when sorted alphabetical are also in chronological order.
The RFC5545 spec allows DTSTART to be specified in UTC time. I'm thinking that's bad though, and could lead to be off by an hour. For example, where I live we honor DST, but parts of Arizona do not. So if the person in Arizona creates an event and it's just stored in UTC, won't I have a "one off" problem when DST switches on or off?
I'm thinking that I should always write the DTSTART and DTEND times with a TZID identifier.
No - the app or program displaying the time should convert the time correctly for the given day. It shouldn't matter what timezone you store the DTSTART in. What matters is correct Timezone transition for the given date by the program that's displaying the time.
So around the daylight saving switchover of a destination. two UTC times will map to the same destination time.
Aside:
There are some very big well known systems don't do Timezone setup for daylight saving zones in the best possible way, but that's a different problem.
DTSTART in UTC is bad mostly in the case of recurring events (especially with attendees). See Should event times specified in UTC while generating ICS files, to avoid issues with myriad calendaring applications for example.
I use ZingChart to show data as a chart. In the char, I show the data following a time which I get from the server. ZingChart is set as default to follow client time.
I found we can set time zone in a chart only as integer value. However, some time zone are UTC+10:30, UTC+04:30...
So how can we set time zone to ZingChart showing correct time? And if that day has Daylight Saving Time, how should I correct it.
JSON scripts
Unfortunately it appears that ZingChart only supports whole-hour time zone offsets. Not only does this not account for time zones with fixed fractional-hour offsets, but it also doesn't properly account for time zones that use daylight saving time.
The example in the documentation says:
... For example, to set the timezone to Pacific Time, you would add: "timezone":-8.
This is incorrect, as Pacific time is only at UTC-8 during standard time. When it's in daylight time, it uses UTC-7.
This is a common mistake. See "Time Zone != Offset" in the timezone tag wiki. My recommendation to the ZingChart developers would be:
Anywhere you support timezone:-8 you should also support fractional hour offsets such as timezone:5.5 or timezone:8.75.
You should also support named time zone identifiers such as "America/Los_Angeles". To make them work, you'll need to provide a function that the developer can hook into. Don't try to implement the function directly, as there are several libraries already available for this. For example, a developer might combine ZingChart with moment-timezone by writing something like:
zingchart.fnTZOffset = function(timestamp, timeZone) {
return moment(timestamp).tz(timeZone).utcOffset() / 60;
}
ZingChart would invoke this function when timezone was a string and would apply the resulting offset to the specific data point.
Without support from ZingChart, there's not much you can do to properly support time zones.
One other solution to the Daylight Savings time issue some ZingChart users have mentioned in the past is MomentJS. http://momentjs.com
I'm developing an international software that act as a simple project management software and I'm facing a problem. This problem is about date/hour and time zone.
When a message is sent from one time zone to another time zone I can store the UTC (GMT) time in my database and then have it displayed differently according to the user's time zone. But this can't be done when I only work with date.
If I say a task is due to the 21st of March. Should I consider that this date can be 20 or 22 in some other countries ? What are your advices on this problem ?
Let's say a user in New York sets a due date for a project as "anytime on Monday 26 January". That means "anytime from 0600 Monday 26 January to 0600 Tuesday 27 January" in Brussels and "anytime from 2000 Sunday 25 January to 2000 Monday 26 January" in L.A.
So completing the task at 2100 on Monday 26 is fine in Brussels and N.Y., but too late in L.A.
One possible work around is never just work with the date. If the time is not specified, either set it for 0000 hrs or 2400 hrs on the date specified in the timezone of the user.
The users may have to deal with strange due dates/times, but speaking as someone who used to work internationally, it kinda goes with the territory.
You won't be able to achieve what you are trying to do without storing the exact time. You simply don't have enough information.
When you don't have a time, assume that the time is the end of business in the main locale for the application, then translate that time as you would any other time. An alternative would be assuming end of the business day in local time and adjust that to UTC. Everyone using the application would need to understand whatever default time assumption you make when the time is not specified. Coordinating to the main office may be best in a large enterprise whereas coordinating to local time may be best in highly decentralized environments where the local context is equally important.
If you aren't storing the minutes and seconds you have to assume that the date being entered is the desired date and not to any adjustments for GMT. Just put it in the database as is. The people on the west coast will have to assume that the due date is the same regardless of where you are in the world. If you want to adjust for time zones, you'll have to collect more information, like hour, minutes, and seconds.
The easiest solution would be just to display as the same date for everyone. The deadline would then effectively be midnight in the latest timezone.
Otherwise, decide what the default time of the deadline should be in the timezone the task was created in, e.g. 21st March 17:00 EST or 22nd March 00:00 EST and display that in the local timezone. The timezone difference will then push it into the previous day or next day accordingly for the viewer.
SQL 2008 allows for a Date datatype that does not have any time value associated with it. That allows someone to say I need this done by this Date, but I don't care if it is +/- several hours. If the date selected is 1/1/2009 but it happens on 1/2/2009 at 2AM their time, they probably don't care.
When the user needs something done by a specific date and time, like close of business on 1/1/2009 then you need to store it in a DateTime as UTC and convert it to local time client-side.
This will take much of the complexity out of indicating when something is completed, it'll either be completed near a specific day or by a specific time.
If you have a single instance of a DB, I would store all dates in the datetime timestamp of your DB server. If you are timestamping rows, consider GetDate() in T-SQL or as default value of the timestamped date column. Then you have your single reference point for all times. Consider UTC format there.
Then, all clients accessing the date do their own conversion into "local time" , which can be interpreted by things like : user preferences, date time stamp on client computer, etc.
Without knowing more, it hard to say exactly what the resolution is.
Your solution depends on your application and requirements.
I'd first store UTC + offset in your data structures, so it's easy to display for any timezone.
Most likely if a task or meeting is due at 12pm on 21/March in London then it will occur at 2130 on 21/March in Adelaide (+0930), but that is an application requirement not any sinister timezone related standard.
If you want the ultimate in flexibility, add a flag that can make the even due simultaneously in every timezone or at the same time no matter where you are (staggered) and show the event accordingly.
You might want to store the date in a from that is timezone aware. This will help you in your calculations. SQL Server 2008 for instance supports a datetimeoffset that does precisely this. Alternatively if you're using SQL 2005 with a bit of effort you can write your own SQL CLR data type to support this.