In hotmail i've the following icalendar that not accepted by hotmail, what is the reason?
Error: Not supported calendar message:
BEGIN:VCALENDAR
PRODID:-//EcosAgile//V1//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:96d3845d-4cc4-4498-bb4d-7a8503b597e6
SUMMARY:Approvazione richiesta Smart working Tomi, Ivio per il 15/09/2017 Buongiorno Tomi, Ivio
le confermiamo che è stata approvata la seguente richiesta:
Codice Richiesta: 151
Causale: Smart working
Data/Ora Inizio: 15/09/2017 - 18:00
Data/Ora Fine: 15/09/2017 - 20:00
LOCATION:
CLASS:BUSY
CATEGORIES:general
CREATED:20170929T143600Z
DTSTAMP:20170929T143600Z
LAST-MODIFIED:20170929T143600Z
X-XM-SHARE:0
DTSTART;TZID=W. Europe Standard Time:20170915T160000Z
DTEND;TZID=W. Europe Standard Time:20170915T180000Z
SEQUENCE:0
ATTENDEE;RSVP=FALSE:MAILTO:valta#agile.com
ORGANIZER:MAILTO:AgileNotifiche#agile.com
END:VEVENT
END:VCALENDAR
IF you put it through the various ics validators, you'll find a bunch of errors. They work differently and do not all pick up everything:
https://icalendar.org/validator.html
Errors
Invalid DTSTART value, The 'TZID' property parameter MUST NOT be applied to DATE-TIME properties whose time values are specified in UTC. near line # 39Reference: 3.3.5. Date-Time
Invalid DTEND value, The 'TZID' property parameter MUST NOT be applied to DATE-TIME properties whose time values are specified in UTC. near line # 39Reference: 3.3.5. Date-Time
http://ical-validator.herokuapp.com:
! Character [,] in property [SUMMARY] should be escaped
Related RFC 5545 section: 3.3.11
! Character [,] in property [SUMMARY] should be escaped
Related RFC 5545 section: 3.3.11
! Invalid name [CAUSALE]. Experimental properties must have the following prefix: X-
Related RFC 5545 section: 3.8.8.2
! Invalid name [DATA/ORA INIZIO]. Experimental properties must have the following prefix: X-
Related RFC 5545 section: 3.8.8.2
! Invalid name [DATA/ORA FINE]. Experimental properties must have the following prefix: X-
Related RFC 5545 section: 3.8.8.2
Related
In a Power Automate / MSFlow flow, I receive a string like this:
Saturday, July 31, 2021 1:35 AM | (UTC+01:00) Dublin, Edinburgh, Lisbon, London
I need to convert it to the format Sharepoint expects, i.e. a ISO 8601 for UTC:
YYYY-MM-DDTHH:MM:SS
I painfully built a flow that does most of the work; however, at the thought of having to manually manage the timezone offset my heart finally gave out. It's shocking that in 2021 a product like this cannot parse a datetime like we could do in any language in 1995.
So my question is: what's the easiest way to parse this datetime correctly in PA/Flow...?
I followed the MS reference:
Workflow definition language functions reference: formatDateTime
And the way to go was with "formatDateTime" function:
formatDateTime('<timestamp>', '<format>'?)
But, before that, the timestamp should be reformated in your case.
My approach will be the following:
Let's assume that the input string will be stored in a variable named timestamp_original.
Take the part before "|" character from the timestamp_original. and remove the Day (at the beginning) from the result.
pass the result to the formatDateTime function.
Use the convertTimeZone function to achieve the TimeZone conversion. (but this part is not working as I expected).
So the final result should be obtained by using the next expressions:
convertTimeZone(formatDateTime(first( split( substring(variables('timestamp_original'), add(2, indexOf(variables('timestamp_original'),','))) , '|' ) )), 'Central Europe Standard Time', 'Greenwich Standard Time')
The solution to the point 3, should be extracting the TimeZone from the timestamp_original string:
trim(first(split(last( split(variables('timestamp_original'), '(' ) ), ')')))
And add some logic to test if this TimeZone contains "UTC+" or "UTC-" and add or extract hours from the obtained timestamp.
I think you can do this.
It should be noted that the variable 'timestamp_original' should be initially in the next format (as the OP mentionned):
Saturday, July 31, 2021 1:35 AM | (UTC+01:00) Dublin, Edinburgh, Lisbon, London
So the result will be: (using the convertTimeZone function)
2021-07-30T23:35:00.0000000
And without using the convertTimeZone function:
2021-07-31T01:35:00.0000000
I hope this has helped. Good luck.
I'm trying to parse this String into a ZonedDateTime:
"Mon 14 Aug 2017 02:00 AM CEST"
Here my last try:
System.out.println("Test ZonedDateTime: " + ZonedDateTime.parse(
"Mon 14 Aug 2017 02:00 AM CEST",
DateTimeFormatter.ofPattern("EEEE dd M yyyy KK:mm a z")));
And the response:
Exception in thread "main" java.time.format.DateTimeParseException: Text 'Mon 14 Aug 2017 02:00 AM CEST' could not be parsed at index 0
at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949)
at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851)
at java.time.ZonedDateTime.parse(ZonedDateTime.java:597)
at be.hypertux.test.localtime.Main.main(Main.java:17)
Any ideas?
One problem is that short timezone names like CEST and CET are ambiguous and not standard. The ideal is to use IANA timezones names (always in the format Continent/City, like America/Sao_Paulo or Europe/Berlin).
I'm assuming that CEST is the Central Europe Summer Time, which is used by lots of different countries (that's why it's ambiguous: you can't know which country or region it is, because it's a too broad range).
Although most abbreviations are not recognized (due to its ambiguity), some "defaults" are assumed for retro-compatibility reasons. In the version I'm using (JDK 1.8.0_131), it defaults to Europe/Paris, but not sure if that's what you need. And it's not guaranteed to work for all abbreviations. In this case, you can define a preferred timezone to be used (and that will an arbitrary choice, but there's no other way since CEST is ambiguous).
Another problem is that the month and day of week are in English (Aug and Mon), and you didn't specify a java.util.Locale. In this case, the DateTimeFormatter takes the system's default locale (and it's probably not English - check the value of Locale.getDefault()). Anyway, the default locale can be changed without notice, even at runtime, so it's better to specify one when you're dealing with localized data (like month and day of week names).
So, you must specify a locale and define an arbitrary timezone as the preferred one to be used when an ambiguous name like CEST is found. For that, you can use a java.time.format.DateTimeFormatterBuilder, a set of preferred timezones and a java.time.format.TextStyle:
// create set of preferred timezones
Set<ZoneId> zones = new HashSet<>();
// my arbitrary choice for CEST
zones.add(ZoneId.of("Europe/Brussels"));
DateTimeFormatter formatter = new DateTimeFormatterBuilder()
// date and time
.appendPattern("EEE dd MMM yyyy hh:mm a ")
// timezone short name with custom set of preferred zones
.appendZoneText(TextStyle.SHORT, zones)
// create formatter (use English locale for month and day of week)
.toFormatter(Locale.ENGLISH);
String input = "Mon 14 Aug 2017 02:00 AM CEST";
System.out.println(ZonedDateTime.parse(input, formatter));
The output will be:
2017-08-14T02:00+02:00[Europe/Brussels]
Note that I used Europe/Brussels as the preferred timezone. You can check all the available zone names (and choose accordingly) with ZoneId.getAvailableZoneIds().
I'm using hh for the hours, which is the hour-clock-of-am-pm field (values from 1 to 12). But in your code you used KK, which is the hour-of-am-pm field (values from 0 to 11). Check which one is best for your case.
A timezone is the set of all different offsets that a region had, has and will have during its history, and the dates when Daylight Saving Time starts and ends, etc. If 2 regions had some difference in this history, they'll have different timezones (even though they use the same rules today).
Just because Paris and Brussels use the same rules today (CET and CEST), it doesn't mean it'll be like this forever (because timezones rules are defined by governments and laws and there's no guarantee that they won't be changed at any time in the future).
That's why you must define some specific timezone instead of relying on ambiguous short names (even though their use is common and widespread).
In order for your format string to work, your date would need to be formatted like so: Monday 14 8 2017 02:00 AM CEST
Take out an E and add a couple of Ms and that should do it.
I want to generate an ics file which will be compatible with google, outlook and apple calendars. I am able to do it fine, but the problem is that I can't specify timezone block in file which will be compatible for above mentioned apps. I currently used X-Wr-timezone property which doesn't work with outlook and gives different time in google. I need the solution for this problem. My ics file:
BEGIN:VCALENDAR
PRODID:-//sample//sam Calendar//EN
VERSION:2.0
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
X-WR-TIMEZONE:America/Los_Angeles
METHOD:PUBLISH
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20160206T074400
DTEND;TZID=America/Los_Angeles:20160206T084400
DESCRIPTION:Your appointment Details:\n\nPatient Details:Kou Kul\nKeven\n\nAppointment Type:Counselling (30 min)\n\nThanks.
LOCATION: Pune
SEQUENCE:0
PRIORITY:5
STATUS:CONFIRMED
SUMMARY:Appointment Details:- John Bond
UID:X:201600U2800000A9Yp0EAF#sample
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
use the VTIMEZONE component before the VEVENT: https://www.rfc-editor.org/rfc/rfc5545#section-3.6.5
BEGIN:VTIMEZONE
TZID:America/New_York
LAST-MODIFIED:20050809T050000Z
BEGIN:STANDARD
DTSTART:20071104T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20070311T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
So the final assembled ICS file would look like this (based on the OP's ICS file; N.B. on his 1st line the "R" of VCALENDAR was pushed to the beginning of "PRODID" on the second line, I have corrected it in the answer):
BEGIN:VCALENDAR
PRODID:-//sample//sam Calendar//EN
VERSION:2.0
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
X-WR-TIMEZONE:America/Los_Angeles
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:America/New_York
LAST-MODIFIED:20050809T050000Z
BEGIN:STANDARD
DTSTART:20071104T020000
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20070311T020000
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTART:20160206T074400
DTEND:20160206T084400
DESCRIPTION:Your appointment Details:\n\nPatient Details:Kou Kul\nKeven\n\nAppointment Type:Counselling (30 min)\n\nThanks.
LOCATION: Pune
SEQUENCE:0
PRIORITY:5
STATUS:CONFIRMED
SUMMARY:Appointment Details:- John Bond
UID:X:201600U2800000A9Yp0EAF#sample
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
I have not tested this specific ICS, so cannot predict the behaviour of using both VTIMEZONE with X-WR-TIMEZONE.
Another point of subtlety is that the Date/Time format cannot include a timezone. So for example if you were to build this in PHP, you'd want to make sure that:
const DT_FORMAT = 'Ymd\THis';
e.g.
DTSTART:20160206T074400
and NOT:
const DT_FORMAT = 'Ymd\THis\Z';
e.g.
DTSTART:20160206T074400Z
This Date/Time format is important for the Date/Times in the VEVENT block. I have had success when there was a "Z" at the end of the "LAST_MODIFIED" field.
On a sidenote, the OP was working in the Los Angeles timezone, but this answer shows New York information in the VTIMEZONE block. The appropriate information for Los Angeles would have to be calculated (e.g. daylight savings offset, etc...)
Final observation, new line "\n" doesn't work with google calendar as of April 2018. iCal obeys it as long as "VERSION:2.0" is used.
Suppose the questioner lives in Los Angeles and uses Latest US-EN version OUTLOOK.
I don't know why specify time zone in New York.
Los Angles is PDT or PST Timezone(written in Japanese)
I find Important Point how to specify timezone on ics file, set 5 Items same value
X-WR-TIMEZONE:America/Los_Angeles
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
DTSTART;TZID="America/Los_Angeles"
DTEND;TZID="America/Los_Angeles"
According to this sight Summer time (daylight saving time - DST ) is recurrent. So, should add RRULE a.k.a Rcurrent rule. Of course, previous code works, well.
Still, even if In September 2019, New Line \n ( means carriage return or/and line feed ) is still valid for Google Calender on Andoroid Smartphones.
And following Item is not so need
UID:
SEQUENCE:0 Befor You use Sequence, Delete added item in scheduler.
BEGIN:VCALENDAR
PRODID:-//Microsoft Corporation//Outlook 19.0 MIMEDIR//EN
VERSION:2.0
X-WR-TIMEZONE:America/Los_Angeles
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
SUMMARY:Appointment
LOCATION:Pune
DESCRIPTION:Your appointment Details:\n\nPatient Details:Kou Kul\nKeven\n\nAppointment Type:Counselling (30 min)\n\nThanks.
DTSTART;TZID="America/Los_Angeles":20160206T074400
DTEND;TZID="America/Los_Angeles":20160206T084400
PRIORITY:5
STATUS:CONFIRMED
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
I have an ace:dateTimeEntry component as below :
<ace:dateTimeEntry id="surveyDate" partialSubmit="true" renderAsPopup="true"
value="#{maintainAppointmentManagedBean.surveyNewDate}"
pattern="dd/MM/yyyy" showButtonPanel="true" navigator="true"
valueChangeListener="#{maintainAppointmentManagedBean.surveyDateChangeListener}">
</ace:dateTimeEntry>
When I manually enter an invalid date such as 21544/10/2012, icefaces converts it to some acceptable format such as 10/12/2020 or similar. It must be doing some background calculation due to which it converts the invalid date to some other date. When it reaches my own validator, the date is already converted into some other date thus my validation has no effect and no message is displayed regarding the invalid date format. There is no JIRA raised to address this. Before I raise this as a bug has anyone else faced this problem or have any solution.
Also, the problem does not occur when pattern="dd/MM/yyyy hh:mm". It occurs only when pattern is pattern="dd/MM/yyyy"
Thanks,
Dakshata Gulkhobare
I tried adding lenientParsing="false" into ace:dateTimeEntry
and it works for me.
dateTimeEntry
I'm looking at the PayPal IPN docs, and it says the datetime stamps of their strings are formatted as:
HH:MM:SS DD Mmm YY, YYYY PST
So year is specified twice?
Once in double digits, and another with 4 digits?
This looks bizarre.
This seems to be a bug in the documentation. The actual format should be "HH:MM:SS Mmm DD, YYYY PST" (e.g. "08:30:06 Apr 19, 2017 PDT")
Actually in PHP you need to use date("Y-m-d\TH:i:s\Z") . That will result in something that looks like 2012-04-30T00:05:47Z -- I didn't notice a difference between urlencoded and non.
Where are you guys finding this info? This information is elusive in their documentation and cost me an hour or two of hunting and trying stuff. The only place I see this format is in the TIMESTAMP field. Having a hard time with the PayPal NVP API's PROFILESTARTDATE for CreateRecurringPaymentsProfile and a "Subscription start date should be valid" error.
For php, the syntax is date("G:i:s M m, Y T");
this is the correct format according to their documentation - 2010-03-27T12:34:49Z
so it is - YYYY-MM-DDTHH:MM:SSZ (I don't know what the T in the middle and Z is but it's constant for all the dates)
I've created PayPal NVP library in Java, so if you want to check how it works, or use it,
you are more than welcome. it's on sourceforge - payapal-nvp.sourceforge.net
Complete date plus hours, minutes, seconds and a decimal fraction of a
second
YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)
Where TZD = time zone designator (Z or +hh:mm or -hh:mm)
Example
1994-11-05T08:15:30-05:00 corresponds to November 5, 1994, 8:15:30 am, US Eastern Standard Time.
1994-11-05T13:15:30Z corresponds to the same instant.
https://www.w3.org/TR/NOTE-datetime
PayPal Format to Any format 100% working and easy copy Paste
$payPalFormat = "18:30:30 Feb 28, 2008 PST";
$subrotoFormat = date('Y-m-d', strtotime($payPalFormat));
Result: 2008-02-29
All Format: https://www.w3schools.com/php/func_date_date.asp
https://gist.github.com/subrotoice/d820863ce65eb0d8434a47a76d005df4 (Subroto Biswas Gist)
Actually, I think the right format is: yyyy-MM-ddTHH:MM:ssZ
The case is important.