I have an icalendar I generate via PHP so people can download the latest schedule to their phones. It works great except that the game times are off by 6 hours on my iPhone. The game time is perfectly fine displaying on Windows calendar.
I've tried playing with the timezones and times but cannot get them to be equal on all platforms.
The calendar is viewable at:
webcal://cal.outbackthunder.com
Dawson,
your ics file at http://cal.outbackthunder.com has the event dates specified in 'local' or 'floating' times.
So the importing app will probably make the events be that time in it's timezone. 8am is 8am in all timezones (think of a travellers alarm clock - where they want to wake at 8m no matter the timezone they are in, vs a reminder to call their partner at 8am in the home timezone, where they'd then want it to adjust to the traveling timezone.)
Either add a Z and issue date-times in UTC, or add the TZID identifer of the timezone.
See https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5.
See these examples in the spec:
Example: The following represents July 14, 1997, at 1:30 PM in New
York City in each of the three time formats, using the "DTSTART"
property.
DTSTART:19970714T133000 ; Local time
DTSTART:19970714T173000Z ; UTC time
DTSTART;TZID=America/New_York:19970714T133000
; Local time and time
; zone reference
Also try running your ics file through as many validators as you can find if you want the general public to be able to use the url. They tend to report slightly differently. EG: one says of http://cal.outbackthunder.com
DATE-TIME value in [DTSTAMP] must be specified in UTC time
Property [ORGANIZER] must be specified once
I am working on a google form. The requirement is to close accepting responses to a google form at a certain time interval (for example, May 03, 2017 local time).
So, what we intend to do is write a script that closes responses to the form as soon as the local machine timestamp (here local machine timestamp is the user machine timestamp) changes to May 04, 2017.
However, all attempts are resulting datetime in timezone set up File/Project Properties/Timezone instead of user's local timezone.
How can we get user's machine date/time so as to compare it with the set time for rejecting responses and apparently close the form.
I am using quickfix .net engine.
StartTime=17:40:00
EndTime=17:25:00
I am running this on a New York server and clock on desktop shows NY local time.
However, the FIX session starts and ends at UTC time. My understanding of fix config was that the times were always Local.
Why might this be happening?
You might need to read the config section properly, once more.
StartTime, EndTime - time in the format of HH:MM:SS, time is represented in UTC
To use local time in the FIX config, you need to set in the config
UseLocalTime=Y
It is N by default. But an important point
Times in messages will still be set to UTC as this is required by the FIX specifications.
I am trying to parse in JAVA a date/time that I receive from an API.
The timestamp I receive looks like this: "Thu Feb 13 12:11:09 IST (Israel) 2014"
I am using Java's SimpleDateFormat, however I do not see anywhere how did the country name, with parentheses, arrive in this string, and how should I parse it.
Is this some standard format I don't know about?
UPDATE:
I am receiving this timestamp from an Android application. The funny thing is the exact same application, running on a different device gives me: "Tue Feb 04 17:36:31 GMT+02:00 2014"
GMT+2 is Israel as well, same timezone, different format... why??
I don't know where android manages the time zone name resources. Anyway, obviously the resource names were changed on this one device (by Google?) with the motivation to avoid duplicates. The abbreviation IST is not unique and can also stand for "Indian Standard Time" which maps to Asia/Colcata instead (while Israel time zone is Asia/Jerusalem).
If you cannot parse "IST (Israel)" then I assume following things: If you parse it by SimpleDateFormat directly on android device then it should probably work. But if you get this string remotely then you can only apply preprocessing of string (filtering out the country) because other devices will not necessarily manage and share the same time zone name resources. You might be able to check directly on android what resources are stored there by calling DateFormatSymbols.getZoneStrings().
Conclusion: You should consider such strings as device-dependent. For data exchange, such formats are not well designed. Instead of using such proprietary formats you should try to use ISO-strings in formats like "yyyy-MM-dd'T'HH:mm:ssXX". Does the API you use offer any alternative format?
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.