Gnu date is usually pretty flexible with input to its --date option. However I find it is not giving me expected results using the ISO-8601 format for week-of-year that I found on wikipedia, namely yyyy-'W'ww or yyyy-'W'ww-d:
$ date -d 2019-W14-2 # expect some variation on 2019-04-02
date: invalid date '2019-W14-2'
Is there any format with which I can ask date to tell me about the 14th week of 2019?
I've tracked the relevant code down to gnulib module parse-datetime. It looks like this would have to be a new feature. I'll update this space if it's ever implemented.
Related
I have about 200 old emails, as *.eml files, that I want to concatenate into one *.org file so that I can use the information in Org mode. Each file has the string "Date: " followed by a timestamp in the RFC 5322 date format, i.e.
Date: Tue, 23 Apr 2019 13:31:18 -0400
I know the UNIX date command can convert the date part of that string to RFC 3339 date format, i.e. the command:
date --rfc-3339='ns' --date='Tue, 23 Apr 2019 13:31:18 -0400'
would give the result:
2019-04-23 13:31:18.000000000-04:00
I guess I could do all the conversion with awk in one go, but my awk is rusty, and I've been having trouble getting it right.
I'd really like to convert all of these dates to Org mode dates with one command, either using a vi command or a doom emacs command.
Any suggestions?
You could build up a regular expression for use with M-x query-replace-regexp which invokes a shell command to use the date command you mention above. The trick is the \, replacement option which allows you to execute any Emacs LISP code, as described in the Regexp Replacement section of the Emacs info manual.
I have a date in the database with this format "YY-mm-dd". On the template I want it in this format: dd.mm.YY
Usually it would work with $date.Format('d.m.Y')
But not in Silverstripe 4. It converts from 2018-05-08 to 8.0.2018. Only the year is correct. Was there a change. I didn't find anything in the Documentation
Date formats in SS4 were changed from PHP date formatting to CLDR date formatting (changelog link):
Changed Format() method to use CLDR format strings, rather than PHP format string. E.g. d/m/Y H:i:s (php format) should be replaced with to dd/MM/y HH:mm:ss (CLDR format).
You can use this to achieve what you want:
$Date.Format('dd.MM.y')
The guide mentioned in the previous answer regarding date formatting has moved. The new location for CLDR date formatting as used by Silverstripe 4 can be found here:
https://unicode-org.github.io/icu/userguide/format_parse/datetime/#date-field-symbol-table
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
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.
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.