I have a virtual assistant app that includes a task manager. Some 'daily' tasks (like 'Check the mail' need to drop off at midnight so they don't clutter up the task list.
We use ISO 8601 to control how long until the task falls off the list.
I've looked all over trying to get clarity on the definition of a "D" day.
For example: Does P1D mean 24 hours? Midnight tomorrow? Midnight tonight?
I'm trying to achieve midnight tonight.
This is an interval, not a specific time of the day and thus it is meaningless without a starting point.
So in this context, this probably means that the task is dropped after 24 hours it had finished.
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 have code that generates icalendar events, including timezone definition for daylight saving.
Timezone for CET/CEST is defined this way:
BEGIN:VTIMEZONE
TZID:Europe/Prague
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:20160327T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:20161030T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
While I believe that this timezone definition is correct and events will have correct offset during STANDARD time (works fine with CEST so far), what can I do to be sure?
I can manually set clock to 30. 10. 2016 3:00, but this way I can't simulate the 3:00 -> 2:00 offset transition that will automatically happen (due to NTP), because I'd have to then set clock manually back one hour, which I think will get me back in time hour before daylight time change.
Is there a way to spoof time with own NTP server or force OS (Linux in this case) to change time offset? Or any other trick to simulate time offset change?
Ok, eventually I figured it out myself.
For programs started in user session should be sufficient to set USER time zone (for example in KDE time applet). But in case of Lightning calendar in Thunderbird, you have to set timezone in Lightning's own settings. And don't forget to close Ligtning window and open it again to apply the change.
For processes outside of user session I assume you would have to change system-wide timezone.
And then set date forward/backward to whatever time you want to test.
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.
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.