RFC 5545 allows the RDATE property to have a data type of PERIOD. What are the semantics of this data type? As far as I can tell, it's unspecified. Does it change the duration of the event? What if it's on a time zone change, which can't have a duration?
Though I agree with you that RFC5545 leaves too many things for interpretation, in this occasion it seems to be giving some guidance for combinationss of PERIOD and RDATE:
For example, recurrence instances of a nominal
duration of one day will have an exact duration of more or less
than 24 hours on a day where a time zone shift occurs. The
duration of a specific recurrence may be modified in an exception
component or simply by using an "RDATE" property of PERIOD value
type.
and
When the combination of the "RRULE" and "RDATE" properties in a
recurring component produces multiple instances having the same
start DATE-TIME value, they should be collapsed to, and
considered as, a single instance. If the "RDATE" property is
specified as a PERIOD value the duration of the recurrence
instance will be the one specified by the "RDATE" property, and
not the duration of the recurrence instance defined by the
"DTSTART" property.
and example is available:
RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
19960404T010000Z/PT3H
Related
I'm using Anylogic and I would like to assign a parameter of type date to each agent (agent is a customer), called DueDate, that represents deadline to his machine failure. My goal is to update value parameter and make it shorter as model time passes (because the failure date is coming). There is some function or code that I can use? I also want to assign a priority parameter to agent that increases when failure date is nearest, so that in queue a customer with a failure nearest is processed before agents with lower priority. How can I do?
Thanks at all
This question seems to contradict itself somewhat. The parameter described is a Due Date, therefore, by definition, should be fixed. Yet, parameter value should be updated as failure date is coming. Do you mean that there should be two parameters: 1) Due Date and 2) remaining time until Due Date? If so this can be achieve like this:
Due Date - if you want to set due date at 10 time units after model start, you can make a parameter (call it p_dueDate of type ) and use timeToDate(100.0) function (help entry).
Remaining time - create a function in the agent f_getRemainingTime() with this code:
return dateToTime(p_dueDate) - time();
where dateToTime() will convert the p_dueDate value back into a double value representing simulation's time units and time() returns current simulation time (also as a double value).
so, let's say for a model starting on 1st Jan with time units = days; offset of 10 will result in p_dueDate = 10th Jan and on 3rd of Jan f_getRemainingTime() will return 7.0.
Section 3.2.19 of RFC 5545 says that a property with a DATE-TIME value must specify a TZID parameter in this situation:
The parameter [TZID] MUST be specified on properties with a DATE-TIME value if the DATE-TIME is not either a UTC or a "floating" time.
The DTSTART property has a DATE-TIME value. Here is an instance:
DTSTART:19970714T133000
Is that a valid property with a "floating" time? Or, is it an invalid property with a "floating" time that erroneously forgot to include the TZID parameter?
When validating an iCalendar file, how do I distinguish between a valid property with a value that is a "floating" time versus an invalid property with a value that is a "floating" time and erroneously forgot to include the TZID parameter?
When validating an iCalendar stream, there is nothing to distinguish. It is always a floating time.
When constructing an iCalendar stream on the other hand, one should
first understand the 3 types defined at https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5 ,
then decide which one is the most appropriate in their application specific context.
finally, based upon 2 (i.e. choice between UTC, local with tz or floating), apply the rule that you referenced in your post.
Please note that client support for floating time is generally poor and unpredictable so you should avoid generating it if you can.
I have an enum TimeFrame that has values like: Yesterday, LastWeek, NextMonth etc.
I'm trying to write a method that takes in a TimeFrame and returns the start and end dates of that period of time.
I looked into the new Java 8 Period class which can take a start time and end time but it doesn't seem there's any clean way to retrieve those values afterwards.
How could I return the start and end date at once cleanly without using a List (seems like the wrong data structure) or some ugly datetime arithmetic?
No, a Period doesn't record a start/end - it just represents the amount of time between them, in a calendrical sense (rather than the "precise amount of time" represented by a Duration).
It sounds like basically you should create your own class that has a start date and an end date. You can still use Period to implement that, but you'd have getStartDate() and getEndDate() returning LocalDate values. You shouldn't need to do any heavy date/time arithmetic yourself - just work out the start date and add the appropriate period, or the end date and subtract the appropriate period, depending on the time frame.
Time marches on
Be careful about passing around enum values for “yesterday”, “tomorrow”, and so on. That raises a couple of issues, time zone and midnight.
Dates and day-of-week only have meaning in the context of a time zone. For any given moment, the date varies around the globe. For example, a few minutes after midnight in Paris is still “yesterday” in Montréal. So when ever you intend “yesterday” and such, always specify the desired/expected time zone as well.
Each non-atomic command and line of code executes separately from the previous. Each execution takes a moment of time, however brief. At any of those moments midnight in the specified time zone may be rolling over into a new day. At that stroke of midnight, your relative-time flag such as “yesterday” suddenly takes on a whole new meaning. That meaning is likely different that was intended by the earlier code given that conditions (the date) were different when that code began.
So it makes more sense to me to be passing around Instant objects, or perhaps OffsetDateTime or ZonedDateTime objects. These date-time values are frozen, representing a specific moment on the timeline. Your earlier original code can verify the meaning of that value, check that the date is indeed a Friday or some such. After such verification, the value can be passed on to other code. Now you need not worry about strange occasional bugs occurring at midnight.
java.time
You don't really need to build a class or enum to express your intention of relative time such as “yesterday”. The java.time classes built into Java 8 and later have plain-reading methods for adding and subtracting days, weeks, months. These are basically one-liners, so just call these plus… and minus… methods directly.
ZonedDateTime now = ZonedDateTime.now();
ZonedDateTime yesterday = now.minusDays( 1 );
ZonedDateTime weekLater = now.plusWeeks( 1 );
That code is implicitly applying the JVM’s current default time zone. Better to specify.
ZoneId zoneId = ZoneId.of( "America/Montreal" );
ZonedDateTime now = ZonedDateTime.now( zoneId );
You may want the date-only without time-of-day and without time zone. Use LocalDate.
LocalDate weekPrior = now.toLocalDate().minusWeeks( 1 );
You may want to get first moment of the day. Not always the time of 00:00:00.0.
ZonedDateTime yesterdayStart = now.minusDays( 1 ).toLocalDate().atStartOfDay( zoneId );
If you want to represent the span of time defined by a pair of date-time values, look at the Interval class found in the ThreeTen-Extra project that extends the java.time framework. This class tracks a pair of Instant objects which are moments on the timeline in UTC. You can extract an Instant from your ZonedDateTime by calling toInstant.
Interval intervalYesterday = Interval.of( yesterdayStart.toInstant() , yesterdayStart.plusDays( 1 ).toInstant() );
To get from an Instant back to a zoned date-time, apply a ZoneId.
ZonedDateTime zdt = ZonedDateTime( instant , zoneId );
For a date-only interval, you'll need to build your own class that stores a pair of LocalDate objects. I would call it something like DateRange.
Tip: Search "Half-Open" to learn about the practice of tracking spans of time where beginning in inclusive while the ending is exclusive.
val date = "01-10-1967"
val pattern = "dd-MM-yyyy"
val formatter = DateTimeFormat.forPattern(pattern)
formatter.parseMillis(date) // this line fails
The last line fails with:
Cannot parse "01-10-1967": Illegal instant due to time zone offset transition (America/Argentina/Buenos_Aires)
Any idea why?
(JodaTime version is 2.3)
The 1st of October 1967 was in Argentina a day where they changed from standard time to summer time, i.e. added 1 hour, on 00:00.
Since you are not providing a concrete time, I would assume that it defaults to exactly 00:00 which simply did not exist on that day.
Cf. the official faq:
What does 'Illegal instant due to time zone offset transition' mean?
Joda-Time only allows the key classes to store valid date-times. For
example, 31st February is not a valid date so it can't be stored
(except in Partial). The same principle of valid date-times applies to
daylight savings time (DST). In many places DST is used, where the
local clock moves forward by an hour in spring and back by an hour in
autumn/fall. This means that in spring, there is a "gap" where a local
time does not exist. The error "Illegal instant due to time zone
offset transition" refers to this gap. It means that your application
tried to create a date-time inside the gap - a time that did not
exist. Since Joda-Time objects must be valid, this is not allowed.
Possible solutions might be (taken from the faq):
Use LocalDateTime, as all local date-times are valid.
When converting a LocalDate to a DateTime, then use toDateTimeAsStartOfDay() as this handles and manages any gaps.
When parsing, use parseLocalDateTime() if the string being parsed has no time-zone.
Since you aren't interested in time information anyway, I think you might even want to replace formatter.parseMillis(date) with formatter.parseLocalDate(date). If for some reason you still need milliseconds, this Stack Overflow question might help.
Is there an "easy" way to create yearly events for "Thanksgiving weekend", meaning an event starting on the 4th Thursday of November (with Sunday as the first weekday), and ending on the following Sunday?
As nearly as I can tell, things like RRULE and RECUR let you create recurring events with zero duration (ie, points in time), but not recurring events that last over a period of time.
What am I missing?
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY:4TH;WKST=SU
You're definitely not restricted to 0 duration events. You can simply specify a DTSTART and DTEND (or DURATION) to get the full weekend.
To elaborate on Evert's answer, to specify a 4 day long event, you just need to specify the DTSTART and DTEND such as below:
DTSTART;VALUE=DATE:20151126 DTEND;VALUE=DATE:20151130 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=4TH;WKST=SU
the justification comes from below section of RFC5545:
RFC5545 3.6.1The "DTSTART" property for a "VEVENT" specifies the inclusive
start of the event. For recurring events, it also specifies the
very first instance in the recurrence set. The "DTEND" property
for a "VEVENT" calendar component specifies the non-inclusive end
of the event.