I have a very strange problem, Zend_Date is converting my timestamp to a year earlier.
In my action:
// Timestamp
$intTime = 1293922800;
// Zend_Date object
$objZendDate = new Zend_Date($intTime);
// Get date
echo date('Y-m-d',$intTime).'<br>';
echo $objZendDate->get('YYYY-MM-dd');
This outputs:
2011-01-02
2010-01-02
Can anyone tell me what i'm doing wrong?
From the ZF issue tracker it seems this is a known issue:
Recently a lot of ZF users are filing a bug that Zend_Date returns the wrong year, 2009 instead of 2008. This is however expected behaviour, and NOT A BUG!
From the FAQ:
When using own formats in your code you could come to a situation where you get for example 29.12.2009, but you expected to get 29.12.2008.
There is one year difference: 2009 instead of 2008. You should use the lower cased year constant. See this example:
$date->toString('dd.MM.yyyy');
instead of
$date->toString('dd.MM.YYYY');
From the manual
Note that the default ISO format differs from PHP's format which can be irritating if you have not used in previous. Especially the format specifiers for Year and Minute are often not used in the intended way.
For year there are two specifiers available which are often mistaken. The Y specifier for the ISO year and the y specifier for the real year. The difference is small but significant. Y calculates the ISO year, which is often used for calendar formats. See for example the 31. December 2007. The real year is 2007, but it is the first day of the first week in the week 1 of the year 2008. So, if you are using 'dd.MM.yyyy' you will get '31.December.2007' but if you use 'dd.MM.YYYY' you will get '31.December.2008'. As you see this is no bug but a expected behaviour depending on the used specifiers.
For minute the difference is not so big. ISO uses the specifier m for the minute, unlike PHP which uses i. So if you are getting no minute in your format check if you have used the right specifier.
To add to zwip's answer, what happens behind the scenes is that your date format YYYY-MM-dd is actually translated into o\-m\-d, which is then passed to PHP's date() function internally with the timestamp you provided.
Like mentioned in the other answer, and in the documentation for the o format on the date format page, the calculation of the year based on the ISO week can sometimes result in the year being one different to the value that you expect.
Related
I have default parameter and this parameter shows me 7 days ago with the expression below:
=DateAdd("d",-7,CDate(Format(Today(), "MM/dd/yyyy")))
But my report just running without error while the customer using "MM/dd/yyyy" time format.
Is there a way to use this parameter ALSO with "dd/MM/yyyy" format?
I would like to set a parameter to show 7 days ago but ı would like to use this parameter with both time format.
Thanks
Don't use the Format. Just put =DateAdd("d",-7,Today()). It will automatically take the Format according to System's format.
Firstly, the format part of your expression is redundant and misleading - don't use it
=DateAdd("d",-7,Today())
Secondly, you don't have any choice of how SSRS displays it's datepickers. It shows american format only (M/d/Y)
A date is a value and values do not have a format. A date is displayed and has to be entered in a format that depends on the language settings of your browser. Using a date picker, you even don't have to care about the input format. So, just use an expression that calculates the desired value:
=Today.AddDays(-7)
The DateTimeFormatter class documentation says about its formatting codes for the year:
u year year 2004; 04
y year-of-era year 2004; 04
…
Year: The count of letters determines the minimum field width below which padding is used. If the count of letters is two, then a reduced two digit form is used. For printing, this outputs the rightmost two digits. For parsing, this will parse using the base value of 2000, resulting in a year within the range 2000 to 2099 inclusive. If the count of letters is less than four (but not two), then the sign is only output for negative years as per SignStyle.NORMAL. Otherwise, the sign is output if the pad width is exceeded, as per SignStyle.EXCEEDS_PAD.
No other mention of “era”.
So what is the difference between these two codes, u versus y, year versus year-of-era?
When should I use something like this pattern uuuu-MM-dd and when yyyy-MM-dd when working with dates in Java?
Seems that example code written by those in the know use uuuu, but why?
Other formatting classes such as the legacy SimpleDateFormat have only yyyy, so I am confused why java.time brings this uuuu for “year of era”.
Within the scope of java.time-package, we can say:
It is safer to use "u" instead of "y" because DateTimeFormatter will otherwise insist on having an era in combination with "y" (= year-of-era). So using "u" would avoid some possible unexpected exceptions in strict formatting/parsing. See also this SO-post. Another minor thing which is improved by "u"-symbol compared with "y" is printing/parsing negative gregorian years (in far past).
Otherwise we can clearly state that using "u" instead of "y" breaks long-standing habits in Java-programming. It is also not intuitively clear that "u" denotes any kind of year because a) the first letter of the English word "year" is not in agreement with this symbol and b) SimpleDateFormat has used "u" for a different purpose since Java-7 (ISO-day-number-of-week). Confusion is guaranteed - for ever?
We should also see that using eras (symbol "G") in context of ISO is in general dangerous if we consider historic dates. If "G" is used with "u" then both fields are unrelated to each other. And if "G" is used with "y" then the formatter is satisfied but still uses proleptic gregorian calendar when the historic date mandates different calendars and date-handling.
Background information:
When developing and integrating the JSR 310 (java.time-packages) the designers decided to use Common Locale Data Repository (CLDR)/LDML-spec as the base of pattern symbols in DateTimeFormatter. The symbol "u" was already defined in CLDR as proleptic gregorian year, so this meaning was adopted to new upcoming JSR-310 (but not to SimpleDateFormat because of backwards compatibility reasons).
However, this decision to follow CLDR was not quite consistent because JSR-310 had also introduced new pattern symbols which didn't and still don't exist in CLDR, see also this old CLDR-ticket. The suggested symbol "I" was changed by CLDR to "VV" and finally overtaken by JSR-310, including new symbols "x" and "X". But "n" and "N" still don't exist in CLDR, and since this old ticket is closed, it is not clear at all if CLDR will ever support it in the sense of JSR-310. Furthermore, the ticket does not mention the symbol "p" (padding instruction in JSR-310, but not defined in CLDR). So we have still no perfect agreement between pattern definitions across different libraries and languages.
And about "y": We should also not overlook the fact that CLDR associates this year-of-era with at least some kind of mixed Julian/Gregorian year and not with the proleptic gregorian year as JSR-310 does (leaving the oddity of negative years aside). So no perfect agreement between CLDR and JSR-310 here, too.
In the javadoc section Patterns for Formatting and Parsing for DateTimeFormatter it lists the following 3 relevant symbols:
Symbol Meaning Presentation Examples
------ ------- ------------ -------
G era text AD; Anno Domini; A
u year year 2004; 04
y year-of-era year 2004; 04
Just for comparison, these other symbols are easy enough to understand:
D day-of-year number 189
d day-of-month number 10
E day-of-week text Tue; Tuesday; T
The day-of-year, day-of-month, and day-of-week are obviously the day within the given scope (year, month, week).
So, year-of-era means the year within the given scope (era), and right above it era is shown with an example value of AD (the other value of course being BC).
year is the signed year, where year 0 is 1 BC, year -1 is 2 BC, and so forth.
To illustrate: When was Julius Caesar assassinated?
March 15, 44 BC (using pattern MMMM d, y GG)
March 15, -43 (using pattern MMMM d, u)
The distinction will of course only matter if year is zero or negative, and since that is rare, most people don't care, even though they should.
Conclusion: If you use y you should also use G. Since G is rarely used, the correct year symbol is u, not y, otherwise a non-positive year will show incorrectly.
This is known as defensive programming:
Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances.
Note that DateTimeFormatter is consistent with SimpleDateFormat:
Letter Date or Time Component Presentation Examples
------ ---------------------- ------------ --------
G Era designator Text AD
y Year Year 1996; 96
Negative years has always been a problem, and they now fixed it by adding u.
Long story short
For 99 % of purposes you can toss a coin, it will make no difference whether you use yyyy or uuuu (or whether you use yy or uu for 2-digit year).
It depends on what you want to happen in case a year earlier than 1 CE (1 AD) occurs. The point being that in 99 % of programs such a year will never occur.
Two other answers have already presented the facts of how u and y work very nicely, but I still felt something was missing, so I am contributing the slightly more opinion-based answer.
For formatting
Assuming that you don’t expect a year before 1 CE to be formatted, the best thing you can do is to check this assumption and react appropriately in case it breaks. For example, depending on circumstances and requirements, you may print an error message or throw an exception. One very soft failure path might be to use a pattern with y (year of era) and G (era) in this case and a pattern with either u or y in the normal, current era case. Note that if you are printing the current date or the date your program was compiled, you can be sure that it is in the common era and may opt to skip the check.
For parsing
In many (most?) cases parsing also means validating meaning you have no guarantees what your input string looks like. Typically it comes from the user or from another system. An example: a date string comes as 2018-09-29. Here the choice between uuuu and yyyy should depend on what you want to happen in case the string contains a year of 0 or negative (e.g., 0000-08-17 or -012-11-13). Assuming that this would be an error, the immediate answer is: use yyyy in order for an exception to be thrown in this case. Still finer: use uuuu and after parsing perform a range check of the parsed date. The latter approach allows both for a finer validation and for a better error message in case of a validation error.
Special case (already mentioned by Meno Hochschild): If your formatter uses strict resolver style and contains y without G, parsing will always fail because strictly speaking year of era is ambiguous without era: 1950 might mean 1950 CE or 1950 BCE (1950 BC). So in this case you need u (or supplying a default era, this is possible through a DateTimeFormatterBuilder).
Long story short again
Explicit range check of your dates, specifically your years, is better than relying on the choice between uuuu and yyyy for catching unexpected very early years.
Short comparison, if you need strict parsing:
Examples with invalid Date 31.02.2022
System.out.println(DateTimeFormatter.ofPattern("dd.MM.yyyy").withResolverStyle(ResolverStyle.STRICT).parse("31.02.2022"));
prints "{MonthOfYear=2, DayOfMonth=31, YearOfEra=2022},ISO"
System.out.println(DateTimeFormatter.ofPattern("dd.MM.uuuu").withResolverStyle(ResolverStyle.STRICT).parse("31.02.2022"));
throws java.time.DateTimeException: Invalid date 'FEBRUARY 31'
So you must use 'dd.MM.uuuu' to get the expected behaviour.
Can anyone tell me why if I type in MATLAB
datestr('17-03-2016','dd-mmmm-yyyy')
I get
06-September-0022
From the datestr docs
DateString = datestr(___,formatOut) specifies the format of the output text using formatOut. You can use formatOut with any of the input arguments in the above syntaxes.
So in your example the 'dd-mmmm-yyyy' is specifying the output format, not the input format.
Also
DateString = datestr(DateStringIn) converts DateStringIn to text in the format, day-month-year hour:minute:second. All dates and times represented in DateStringIn must have the same format.
where
'dd-mm-yyyy' is not in the list of allowed DateStringIn formats AND the documentation explicitly recommends using datenum to ensure correct behaviour. (Note: I underlined the wrong must in the sentence, it's the second must I wanted to emphasise)
So Sandar_Usama's answer of
datestr(datenum('17-03-2016','dd-mmmm-yyyy'))
is the officially correct method straight out of the docs.
Bottom line, always read the documentation.
Use this instead: datestr(datenum('17-03-2016','dd-mmmm-yyyy'))
To address the last unanswered point in this question, why does datenum behave like this?
>> datestr(datenum('17-03-2016'))
ans =
06-Sep-0022
Without explicitly telling datestr and datenum how it should treat the input, it will try to match against the expected formats. Since none of the documented formats match (see #dan's answer), it fails.
Although what it does next is undocumented, at least up to whatever version of Matlab we are running, it falls into a "last resource" attempt to give you a date number.
Matlab will try to parse different month names from your input, remove non-numeric characters, and then timedate elements from the string. In your case, they are 17, 03, and 2016. The first is expected to be either month or year. Since there's no 17th month, it is treated as year. Then 03 is the month, and 2016 is the day.
Now, March 2016th, 17 is not a valid date, but Matlab will give it a slack and read as 1985 days past March 31st, 17. And that gives us September 6th, 22.
Because Matlab's timestamp is a floating number for the number of days since its epoch, you can trigger that answer, using valid dates, like so:
>> datestr(datenum('0017-03-31') + 1985)
ans =
06-Sep-0022
As an absolute beginner to SAS I quickly ran into problems with date formatting.
I have a dataset containing transaction with three types of dates: BUSDATE, SPOTDATE, MATURITY. Each transaction is represented on two lines, and I want BUSDATE and SPOTDATE from line 1 but MATURITY from line 2.
In the original set, the dates are in YYYY-MM-DD format.
DATA masterdata;
SET sourcedata(rename(BUSDATE=BUSDATE2 SPOTDATE=SPOTDATE2 MATURITY=MATURITY2));
BUSDATE=BUSDATE2;
SPOTDATE=SPOTDATE2;
IF TRANS_TYPE='Swap' THEN;
MATURITY=SPOTDATE;
RUN;
Problem is, this returns something like 17169 (which I guess is the number of days from a certain date).
How can I make it output in YYYY-MM-DD format - or is this approach wrong; should I first convert the date variables to some SAS date format?
if you have valid SAS dates, just add a FORMAT statement to your DATA STEP.
Format busdate spotdate maturity yymmdd10. ;
SAS dates are numeric variables. They represent the number of days since 1/1/1960. You use a FORMAT to display dates.
Adding to CarolinaJay's answer, you normally want to keep them as numeric format, since you can do math (like "# of days since date X") with them. However, if for some reason you need a character variable, you can do this:
date_As_char=put(datevar,YYMMDD10.);
Incidentally, YYMMDD10 will actually give you YYYY-MM-DD, as you asked for; if you want a different separator, see http://support.sas.com/documentation/cdl/en/lrdict/64316/HTML/default/viewer.htm#a000589916.htm (YYMMDDxw. format) - if you put a letter after the last D, for certain letters, you get a different separator. Like, YYMMDDn10. gives you no separator, or YYMMDDs10. gives you slashes. YYMMDDd10. gives you dashes, just like omitting the letter would. This concept also applies to MMDDYY formats, and I think a few others.
Today is April 25, 2009 which in US format is abbreviated month-day-year, so today is 04-25-09. This line
> CurrentTime().toString("%m-%d-%y")
should print "04-25-09". Instead it prints "05-25-09". Why is that? According to the docs CurrentTime() returns a TimeStamp instance. TimeStamp has a toString() method which accepts a date/time format as a parameter, which is supposed to be in
strftime format. Is there something wrong with my understanding of the code? I am using Falcon 0.8.14.2("Vulture") on Windows Vista (64-bit)
2: http://linux.die.net/man/3/strftime strftime format
I also posted this question on the Falcon Google Group. Apparently, this is an issue with Falcon itself and is fixed in version 0.9.1. Version 0.9.1 will be officially released in a week or two according to the response I received from Giancarlo Niccolai, the inventor of the Falcon programming language.