Icalendar dates problem - my date is out by 2 days - icalendar

I have a calendar file which I will post below. The problem is that when I load this into outlook the date says the 24/02/2011. The date in the file as shown below is the 22/02/2011
(START:201102*22*T100000).
I am in Sydney/Australia if that makes any difference.
Can anyone try adding this to their outlook calendars and see if the date is wrong?
Here is a link to the file: http://www.onlinerego.com/small_business_summit2011/assets/template/ics/sydney.ics
Thanks so much.
BEGIN:VCALENDAR
PRODID:-//http://testing.cdw/thegoldbook///NONSGML kigkonsult.se iCalcreator 2.8//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
UID:20110208T111839EST-4800GDFvWN#http://testing.cdw/thegoldbook/
DTSTAMP:20110208T000239Z
DESCRIPTION;LANGUAGE=en:Thank you for registering to attend the 'Trend Micr
o Affinity Partner Small Business Summit 2011'.\n\nWe look forward to seei
ng you at the event!\n\nDate: 22 February\nVenue: Novotel Darling Harbour\
, Terrace Room\nAddress: 100 Murray St\, Darling Harbour\nArrival time: 10
:00am\n\nAgenda\n10.00am - Pre registration & Networking\n10.30am - Exploi
ting Small Business Trends to increase your profits\, By Toby Lee\, Global
Vice President\, Volume Business Unit\, Trend Micro\n11.00am - Product Ro
admap for Small Business\, By Richard Ku\, Global Vice President\, Small B
usiness Product Management\, Trend Micro\n11.15am - Break\n11.45am - Affin
ity Program and Channel Engagement Update\, By Malcolm Pooley\, ANZ Small
Business Channel Sales Manager\n12.00pm - Q&A Panel\n12.15pm - Close\n\nUR
L - http://www.onlinerego.com/small_business_summit2011/thankyou.php?city=
Sydney
DTSTART:20110222T100000
DTEND:20110222T121500
LOCATION;LANGUAGE=en:Novotel Darling Harbour\, Terrace Room\, 100 Murray St
\, Darling Harbour
SUMMARY;LANGUAGE=en:Trend Micro Affinity Partner Small Business Summit 2011
URL:http://www.onlinerego.com/small_business_summit2011/thankyou.php?city=S
ydney
END:VEVENT
END:VCALENDAR

I'm also in Aus.
Loading into my google (sydney time) gives Tue, 22 February, 21:00 – 23:15 - so wrong times but right date. Google may assume it is UTC time and are we currently +11, that may explain it's time. No idea what outlook is doing.
windows calendar has 22 feb and 10 am
my own app also gives 22 Feb and 10 am
The way dates are specified and whether you have a timezone or not makes a difference.
The file does not have a timezone spec and the dates are specified in "local" format - ie: should translate to 10 am in whatever timezone you load it into ... dangerous as if it were a conference call meeting across timezones for eg, it should have a timezone associated with it.
Either in the DTSTART
DTSTART;TZID=America/New_York:20101031T190000
or using the X-WR-TIMEZONE custom field
X-WR-TIMEZONE:America/New_York
Sorry no idea what outlook is doing though (I do not use it).

Related

Org icalendar export : don't make tickler for one hour

When exporting an org mode file to .ics, everything works fine.
The problem is not with the export, but with the length of time that an event that takes place at a specific time (without an end date) lasts (This is what I call a "tickler" (event to be checked or thought of at some point)).
The time duration is 2 hours, which is much too long for a tickler.
Here is an example: 
* Try of tickler <2022-06-09 Thu 22:00> Description
BEGIN:VEVENT
DTSTAMP:20220609T202654Z
UID:TS1-940a4198-e83d-4bf0-b839-baa1bdb36e54
DTSTART:20220609T200000
DTEND:20220609T220000
SUMMARY:Try of tickler
DESCRIPTION:<2022-06-09 Thu 22:00> \nDescription
END:VEVENT
Why does org-mode work like this? Can we reduce the duration of the time? Thanks in advance for your answers

I cannot figure out what date format this is

I've got these ical files I'm trying to process and they come with microsoft teams links. The invites have this very strange format for the date that I just can't figure out. I thought it was UTC but I still can't seem to figure it out. Any calendaring program opens it just fine, showing me the correct date. But I want to process the text.
Here is an example:
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Central Standard Time
BEGIN:STANDARD
DTSTART:16010101T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
This one in particular converts to October 27, 2021 at 3:00pm Central Daylight time. I could process things another way, but I have to satisfy my curiosity here. I tried to look at the RFC for ICS but I haven't seen what I'm looking for.
Those are daylight saving changes for the timezone component. https://datatracker.ietf.org/doc/html/rfc5545#section-3.6.5
"DTSTART" in this usage MUST be specified as a date with a local time value.
For local time value, see Form#1 for DATETIME https://datatracker.ietf.org/doc/html/rfc5545#page-33

Why AlphaVantage doesn't provide recent data [duplicate]

I am trying to get the latest Intraday prices from Alpha Vantage API. Currently it is Friday, 9:16PM Eastern European Time. I am trying to get Tesla stock. Markets are still open. However, The API call returns me yesterday's data only. What could be the problem?
ts = TimeSeries(key='API_KEY', output_format='pandas')
data, meta_data = ts.get_intraday(symbol='TSLA',interval='1min', outputsize='full')
print(data.head(5))
print(meta_data)
1. open 2. high 3. low 4. close 5. volume
date
2020-04-16 16:00:00 746.06 746.830 745.530 745.6800 83342.0
2020-04-16 15:59:00 746.57 746.715 745.090 746.1958 53268.0
2020-04-16 15:58:00 746.90 747.465 746.490 746.6250 36746.0
2020-04-16 15:57:00 747.52 747.760 746.827 747.2147 25910.0
2020-04-16 15:56:00 747.95 747.990 746.800 747.2800 33869.0
{'1. Information': 'Intraday (1min) open, high, low, close prices and volume', '2. Symbol': 'TSLA', '3. Last Refreshed': '2020-04-16 16:00:00', '4. Interval': '1min', '5. Output Size': 'Full size', '6. Time Zone': 'US/Eastern'}
1. open 2. high 3. low 4. close 5. volume EMA
I had the same problem and wasn't able to solve it yet. But in my case only some stocks are not up to date. For example 'IBM' is up to date but 'TSLA' and 'AAPL' not. I also have written an email to the technical support 2 days ago. If I ever get a response with the explanation I will write you. I have checked this not only with the python module also with the direct API call.
My code:
https://github.com/SebNik/TradingBot
I also noticed this and contacted Alpha Vantage. I got this response:
Thank you for reaching out! For Nasdaq-listed securities such as MSFT, the data is refreshed daily at 4:30pm ET on our API platform.
So looks like real-time data is not provided for Nasdaq-listed items. This could be the issue here.

BlackBerry date parsing and an hour's difference

Due to the limitation of date parsing on BlackBerry I'm trying to roll my own parse/deparse methods, however I seem to be falling foul of an hour's difference somewhere, somehow.
I do this:
long nowLong = System.currentTimeMillis();
String nowString = DateParser.longToString(nowLong);
Date nowDateFromString = DateParser.stringToDate(nowString);
Date nowDateFromLong = DateParser.longToDate(nowLong);
When outputted in order it produces this in console:
[139.46] 1369132556831
[139.46] 21 May 2013 11:35:56 Europe/Dublin
[139.46] Tue May 21 12:35:56 Europe/Dublin 2013
[139.46] Tue May 21 11:35:56 Europe/Dublin 2013
My simulator's time is set to 11:35 so the third statement - DateParser.stringToDate() - seems to be failing somewhere.
Here is my implementation:
public static Date stringToDate(String date) {
long l = HttpDateParser.parse(date);
Date d = new Date(l);
return d;
}
As my nowString includes the time zone I'd expect HttpDateParser.parse() to take this in to account but it seems not to be.
How can I correct this?
HttpDateParser.parse() is documented to handle "GMT" or a "TZD" which I assume to be a "time zone designator". I suspect this is expected to be the (horrible, ambiguous) abbreviation format - so for example, it might be worth trying to parse
21 May 2013 11:35:56 BST
and seeing what you get out. That would at least take you further in terms of diagnosing the behaviour of HttpDateParser. Keeping the time zone's TZDB ID is a better idea in my view, but you may well need to write your own parsing code. You still need to handle local time ambiguity though, where a particular local time occurs twice due to DST transitions.
It's not entirely clear what the input or expected output are in your case - how much control you have over the format. I'd try to use ISO-8601 as far as possible, with a time zone identifer as well if you need one. (If you're only trying to represent an instant in time, I'd use an ISO-8601 representation of the UTC instant, complete with a Z suffix to indicate UTC.)

Timezones not working for calendar event

I am having difficulties with timezones in an event. This is the contents of the event, and it's specifying the event with a TZID. I am being told however that when people in Central timezone add it, it appears as 2PM rather then intended 1PM. I am in ET so not able to test this.
Do you know why it would be happening?
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//http://XXX//Event
METHOD:PUBLISH
BEGIN:VEVENT
DTSTART;TZID="America/Chicago":20150811T130000
DTEND;TZID="America/Chicago":20150811T141500
SUMMARY:Test Event
DESCRIPTION:Test Event
LOCATION:Test Event Location
END:VEVENT
END:VCALENDAR
See RFC5545, Time Zone Component and Time Zone Identifier: you need to add a VTIMEZONE component to your calendar file where you definea TZID so that you can refer to it in your VEVENT.
Parameter Name: TZID
This parameter MUST be specified on the "DTSTART",
"DTEND", "DUE", "EXDATE", and "RDATE" properties when either a
DATE-TIME or TIME value type is specified and when the value is
neither a UTC or a "floating" time. Failure to include and follow VTIMEZONE definitions in iCalendar objects may lead to inconsistent understanding of the local time
at any given location.
It should be noted that while Outlook/Exchange have repeatedly been reported to not require the VTIMEZONE, failure to include a VTIMEZONE leads to unpredictable behaviour from other calendars.