i need a correct weekly ISO 8601 recurring time interval.
For example, repeat:
Each Monday, 19:00.
I already tried a lot of examples, but nothing worked correctly :-(
Thx for any help!
R/2014-W01-1T19:00:00/P1W
Represents a unbounded recurrence with a start date and a duration of one week. The recurrence starts at the first day (Monday) of the week number 01 in the week year 2014. I have used a week date, but you can substitute it with a calendar date or ordinal date, just make sure the date falls on a Monday.
Related
i have this problem, there is a system thats has the duty to deliver a message in the future in a certain date, like a time limit, so this system is in another country thats have the time zone -4 hours and the country thats recibe the message is in a time zone -3 hours, for this country are Chile and Brazil, the problem is, this countries when they enter to the summer time they add one hour, but in different dates, for a period of time like 4 months thy have the same time zone, so for me to deliver the message in the right time i have to add one hour to the date in when the time zone are in -4 and - 3 but when the time zone match -3 hours i dont have to do nothing.
for this task i want to use the function time.LoadLocation("America/Sao_Paulo"), but reading the documentation dosen't mention if they fix the time zone when this countries change their time zone.
does anyone know if they adjust the time zone, or know another function thats can work in this situation?
Areas that observe daylight savings time don’t change the time zone, they change the time standard. For instance, Los Angeles observes a given time eight hours before UTC for much of the year, but seven hours before UTC during the summer; yet Los Angeles is always “Pacific time”.
If you set the time zone to "America/Sao_Paulo", times will be measured relative to Sao Paulo’s then-active time standard.
Date.new results in # -4712-01-01.
Just as per the title, what logic am i missing, why start from -4712?
https://en.wikipedia.org/wiki/Julian_day
The Julian Period is a chronological interval of 7980 years beginning 4713 BC. It has been used by historians since its introduction in 1583 to convert between different calendars. 2015 is year 6728 of the current Julian Period. The next Julian Period begins in the year 3268 AD.
The internal representation of a Date or DateTime object is an astronomical Julian date: a fractional number of days since a "time zero" in 4712 BCE.
More information are also available in the Ruby documentation for Date.
The Julian day number is in elapsed days since noon (Greenwich mean time) on January 1, 4713 BCE (in the Julian calendar).
In this document, the astronomical Julian day number is same as the original Julian day number. And the chronological Julian day number is a variation of the Julian day number. Its days begin at midnight on local time.
From Wikipedia
The Julian day number can be calculated using the following formulas (integer division is used exclusively, that is, the remainder of all divisions are dropped):
The months (M) January to December are 1 to 12. For the year (Y) astronomical year numbering is used, thus 1 BC is 0, 2 BC is −1, and 4713 BC is −4712. D is the day of the month. JDN is the Julian Day Number, which pertains to the noon occurring in the corresponding calendar date.
How can I check whether an email was sent this week or not from the datetime parsed from the email? For today we can do:
yourdatetime.date() < datetime.today().date()
But for a week, first we need to define what a week is, which in our case is all emails since the previous Friday. I should be able to compute it by hand, but trying to see if there are datetime functions I can use to make the code more readable for the next person.
The best you could get directly would be the use of strftime to get the week number. Extract from the page on strftime() and strptime() Behavior :
%U : Week number of the year (Sunday as the first day of the week) as a zero padded decimal number. All days in a new year preceding the first Sunday are considered to be in week 0. Output : 00, 01, ..., 53
%W : Week number of the year (Monday as the first day of the week) as a decimal number. All days in a new year preceding the first Monday are considered to be in week 0. Output : 00, 01, ..., 53
But ... this only accept either monday or sunday as first day of the week, neither friday, nor saturday. If it is not enough, you will have to develop your own algorythm in a dedicated function.
Hi we have requirement to determine week of date by considering "Sunday to Saturday" as one week but i went through the link [oracle function][1]
[1]: http://www.techonthenet.com/oracle/functions/to_char.php here there are options like 'IW'(week of year ISO standard) which calculates week of year by considering Monday to Sunday as one week but we have specs to consider "Sunday to Saturday" as one week.Can any one suggest how to calculate ?
In order to determine the "week number" you need basically two informations:
On which day does your week start? This you provided, week begins on Sunday
Which week do you consider as first week of the year? This you did
not tell us.
The second definition may overrule the first one, e.g. "week 1 starts on the first day of the year and continues to the seventh day of the year." as used in Oracle TO_CHAR(..., 'WW')
I'm looking for a better than O(n) algorithm to determine if a date in the future will have daylight savings time applied (and how much). Given a year, month, day, hour, minute and time zone (and a copy of the Olsen Time Zone database) how does one efficiently determine if that date will be in DST? I'm looking for the algorithm, not a library function to call.
Thank you.
FURTHER EXPLANATION: The date library I'm using is very slow when you create an object with a date in the future and a time zone. It turns out its doing a linear calculation to calculate if the date is in daylight savings time. Not only that, its doing this at object creation time. Obviously it could wait until asked, but it should also be more efficient.
Sure, DST rules change and a date library can't predict the future, but the alternative is to put an arbitrary upper limit on localized dates.
Everybody's already commented on the problems with always-changing DSTs. But I can accept the premise that we just pretend the currently known rules will apply forever.
To get your DST information, the first thing to do is to calculate the year/month/day for your future date (if it isn't in that form already). Then you look up your time zone and pull out the variation against UTC, the DST on/off rule and offset. There could be several different rules depending on which year, you want to be sure to grab the right one for your "target" year. For reasons explained below, it may be handy to also be aware of the rules for the preceding year.
The on/off rules will have a funny spec like "Oct lastSun": That means the switch occurs in the night of the last Sunday in October.
What you need to do is gather up all of these tersely formatted "rules" and develop a bit of code for each to determine the last date indicated by that rule. It's currently December, so given a couple of rules like "Mar lastSun" and "Oct lastSun" for my time zone, those dates would be March 29, 2009 and October 25, 2009. Which of these dates is more recent? October. October is associated with an "off", so we must currently have NO DST.
You can calculate the DST on/off dates for the current (i.e. target) year regardless of whether the target date is before or after those dates; if the on/off date is in the future of your target date, then simply do the rule calculation again for the previous year. Note that the rules may have changed during the interval, so be sure to apply the correct one for the year you're looking at.
Worst case for this calculation is, you have to repeat your two rule calculations for the previous year. But there's no searching going on otherwise, so it's strictly O(1).
I found a Local/DST/Tz calculator here: http://home-4.tiscali.nl/~t876506/WhatDay.html and as it's a JavaScript applet you should be able to simply crib the code. It doesn't handle all rules, though, so you will need to add some code for the remaining rules.
Update: I just noticed you have an hour and minute in your time as well. That complicates matters just a little. If your date is not on a "switch" date then the instructions I gave above will do you fine. Otherwise, you need to consider the time. I guess the cleanest thing to do would be to include the time in your determination of "most recent". I.e. if your target time is 00:30 UTC and switch time for the given zone is 01:00, then the target year's switch time is still in the future and you have to use the previous year's switch time instead. For practical purposes, this will mean that the "other" switch time was the most recent, and its on/off status applies.
Your number one problem is daylight savings rules that are set by the local authorities. The latter can pass almost any law at any time and therefore change the rules in a way you can't possibly predict.
As far as I know DST changes that are known start and end on a fixed day each year (first weekend in april, last weekend in october, stuff like that). So you could ese the Doomsday Algorithm to find the days of the week for the given year and calculate the conversion dates from that. Then you can determine if DST is in effect in source and/or destination locale. The converion itself is simply a matter of adding and/or subtracting an hour to compensate for DST and then factor in the timezone difference.
Hmm, as I see the problematic point is to determine weekday for a given day, far in the future.
For that, I suggest something like that:
after every 400 years, the complete system turns around, so first divide the number of years with 400, take the integral part. In 400 years, there are 99 leap years and 301 simple ones. If an arbitrary day is Monday, then the same day 400 years later will be 301+2x99 = 499 (mod 7) ---> Monday+2 ---> Wednesday. So you have to say something like that:
wday = (ref_day + 2 * (int)((target_year - ref_year) / 400)) mod 7
then you can do further optimizations, but I guess you can go year-by-year, that will do it. At most you make 399 simple operations, if (leap_year) then ++ else +=2, mod 7.
After you have the weekday for Jan 1 that year, you can calculate DST switching dates, as Carl Smotricz has written.