In my YAML Header I try this for date:
date: "`!expr format(Sys.time(), '%B %d, %Y')`"
date-format: dddd, D MMM YYYY
lang: de
But if I render I receive an error message:
Invalid Date
Did I use !expr in the correct way?
Related
I get a Date in the following format from an api:
Mon Apr 29 14:40:17 2019
I try to parse it to a valid powershell Date with the following command:
$test = [DateTime]::ParseExact("Mon Apr 29 14:40:03 2019", "ddd MMM dd HH:mm:ss yyyy",$null)
Powershell returns "Exception calling "ParseExact" with "3" argument(s): "String was not recognized as a valid DateTime."
It seems that the problem occurs because of the abbreviated weekday format. If I remove "Mon" and "ddd" the parse works.
The information about the Format specifier is from: https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings#dddSpecifier
Anyone knows what causese the error?
Replacing $null with [System.Globalization.CultureInfo]::InvariantCulture solved the problem.
The working code is:
$test = [DateTime]::ParseExact("Mon Apr 29 14:40:03 2019", "ddd MMM dd HH:mm:ss yyyy",[System.Globalization.CultureInfo]::InvariantCulture)
I have some saved dates in JavaScript using new Date() that looks like:
"Sun Feb 24 2019 14:44:20 GMT+0200 (Eastern European Standard Time)"
I'm trying to parse these to Elixir DateTime; I didn't find anything in "timex" that can help and I already know that I can use DateTime.from_iso8601 but for dates saved using new Date().toISOString() but what i need is to parse the above string.
Thanks in advance
You can use elixir binary pattern matching to extract the date parts and parse using Timex's RFC1123 format. The RFC1123 is the format e.g Tue, 05 Mar 2013 23:25:19 +0200. Run h Timex.Format.DateTime.Formatters.Default in iex to see other formats.
iex> date_string = "Sun Feb 24 2019 14:44:20 GMT+0200 (Eastern European Standard Time)"
iex> <<day_name::binary-3,_,month_name::binary-3,_,day::binary-2,_,year::binary-4,_,time::binary-8,_::binary-4,offset::binary-5,_,rest::binary>> = date_string
iex> Timex.parse("#{day_name}, #{day} #{month_name} #{year} #{time} #{offset}", "{RFC1123}")
iex> {:ok, #DateTime<2019-02-24 14:44:20+02:00 +02 Etc/GMT-2>}
Pattern matching:
The binary-size are in byte sizes. 1 byte == 1 character. For instance to get
3-character day_name the size is 3. Underscores (_) is used to pattern match the spaces in the date format
Updated answer to use binary-size rather than bitstring-size for simplicity
I didn't find anything in "timex" that can help
The Timex Parsing docs say that you can use strftime sequences, e.g %H:%M:%S, for parsing. Here's a list of strftime characters and what they match.
Here's a format string that I think should work on javascript Dates:
def parse_js_date() do
Timex.parse!("Sun Feb 24 2019 14:44:20 GMT+0200 (Eastern European Standard Time)",
"%a %b %d %Y %H:%M:%S GMT%z (%Z)",
:strftime)
end
Unfortunately, %Z doesn't want to match the time zone name, which causes Timex.parse!() to spit out an error. It looks like %Z in Elixir only matches one word, e.g. a timezone abbreviation EET. Therefore, my simple, clean solution is spoiled.
What you can do is chop off the time zone name before parsing the date string:
def parse_js_date_string() do
[date_str|_tz_name] = String.split(
"Sun Feb 24 2019 14:44:20 GMT+0200 (Eastern European Standard Time)",
" (",
parts: 2
)
Timex.parse!(date_str,
"%a %b %d %Y %H:%M:%S GMT%z",
:strftime)
end
In iex:
~/elixir_programs/my$ iex -S mix
Erlang/OTP 20 [erts-9.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false]
Compiling 1 file (.ex)
Interactive Elixir (1.6.6) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> My.parse_js_date_string()
#DateTime<2019-02-24 14:44:20+02:00 +02 Etc/GMT-2>
iex(2)>
I'm trying to change date format from 08/03/2017
08 day
03 Month
2017 year
I I'm using
date("d F Y", strtotime($date));
the problem is that I Get 03 August 2017 instead of 08 March 2017
PS : I can't use any other then
dd/mm/yyyy
Try this
$date = DateTime::createFromFormat('d/m/Y', "08/03/2017");
echo $date->format('d F Y');
You can check it to http://php.net/manual/en/datetime.createfromformat.php
After Some researchs I found a solution
str_replace(' / ', '-',$date)
/*
You got August because you provide wrong format to this function. Function accept m/d/y and you provide d/m/y. you can try with this format m/d/y
or
you can try this with DateTime object.
*/
$date = "08/03/2017";
$dateObject = DateTime::createFromFormat('d/m/Y', $date);
echo $dateObject->format('d M Y');
I have some date other than current date in unix and I want to convert into a specific format
Original Format
D="Mon Dec 30 06:35:02 EST 2013"
New Format
E=20131230063502
E=`date +%Y%m%d%H%M%S`
this is the way to format the output of the date command and save it in the variable E
Using python:
def data(dstr):
m = {'Jan': '01', 'Feb':'02', 'Mar':'03', 'Apr':'04', 'May':'05', 'Jun':'06', 'Jul':'07', 'Aug':'08', 'Sep':'09', 'Oct':'10', 'Nov':'11', 'Dec':'12'}
val = dstr.split(' ')
month = m[val[1]]
time = val[3].split(':')
return '{}{}{}{}{}{}'.format(val[-1],month,val[2],time[0],time[1],time[2])
if __name__ == '__main__':
print data("Mon Dec 30 06:35:02 EST 2013")
In: Mon Dec 30 06:35:02 EST 2013
Out: 20131230063502
How can I elegantly print the date in RFC822 format in Perl?
use POSIX qw(strftime);
print strftime("%a, %d %b %Y %H:%M:%S %z", localtime(time())) . "\n";
The DateTime suite gives you a number of different ways, e.g.:
use DateTime;
print DateTime->now()->strftime("%a, %d %b %Y %H:%M:%S %z");
use DateTime::Format::Mail;
print DateTime::Format::Mail->format_datetime( DateTime->now() );
print DateTime->now( formatter => DateTime::Format::Mail->new() );
Update: to give time for some particular timezone, add a time_zone argument
to now():
DateTime->now( time_zone => $ENV{'TZ'}, ... )
It can be done with strftime, but its %a (day) and %b (month) are expressed in the language of the current locale.
From man strftime:
%a The abbreviated weekday name according to the current locale.
%b The abbreviated month name according to the current locale.
The Date field in mail must use only these names (from rfc2822 DATE AND TIME SPECIFICATION):
day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun"
month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
"Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
Therefore portable code should switch to the C locale:
use POSIX qw(strftime locale_h);
my $old_locale = setlocale(LC_TIME, "C");
my $date_rfc822 = strftime("%a, %d %b %Y %H:%M:%S %z", localtime(time()));
setlocale(LC_TIME, $old_locale);
print "$date_rfc822\n";
Just using POSIX::strftime() has issues that have already been pointed out in other answers and comments on them:
It will not work with MS-DOS aka Windows which produces strings like "W. Europe Standard Time" instead of "+0200" as required by RFC822 for the %z conversion specification.
It will print the abbreviated month and day names in the current locale instead of English, again required by RFC822.
Switching the locale to "POSIX" resp. "C" fixes the latter problem but is potentially expensive, even more for well-behaving code that later switches back to the previous locale.
But it's also not completely thread-safe. While temporarily switching locale will work without issues inside Perl interpreter threads, there are races when the Perl interpreter itself runs inside a kernel thread. This can be the case, when the Perl interpreter is embedded into a server (for example mod_perl running in a threaded Apache MPM).
The following version doesn't suffer from any such limitations because it doesn't use any locale dependent functions:
sub rfc822_local {
my ($epoch) = #_;
my #time = localtime $epoch;
use integer;
my $tz_offset = (Time::Local::timegm(#time) - $now) / 60;
my $tz = sprintf('%s%02u%02u',
$tz_offset < 0 ? '-' : '+',
$tz_offset / 60, $tz_offset % 60);
my #month_names = qw(Jan Feb Mar Apr May Jun
Jul Aug Sep Oct Nov Dec);
my #day_names = qw(Sun Mon Tue Wed Thu Fri Sat Sun);
return sprintf('%s, %02u %s %04u %02u:%02u:%02u %s',
$day_names[$time[6]], $time[3], $month_names[$time[4]],
$time[5] + 1900, $time[2], $time[1], $time[0], $tz);
}
But it should be noted that converting from seconds since the epoch to a broken down time and vice versa are quite complex and expensive operations, even more when not dealing with GMT/UTC but local time. The latter requires the inspection of zoneinfo data that contains the current and historical DST and time zone settings for the current time zone. It's also error-prone because these parameters are subject to political decisions that may be reverted in the future. Because of that, code relying on the zoneinfo data is brittle and may break, when the system is not regulary updated.
However, the purpose of RFC822 compliant date and time specifications is not to inform other servers about the timezone settings of "your" server but to give its notion of the current date and time in a timezone indepent manner. You can save a lot of CPU cycles (they can be measured in CO2 emission) on both the sending and receiving end by simply using UTC instead of localtime:
sub rfc822_gm {
my ($epoch) = #_;
my #time = gmtime $epoch;
my #month_names = qw(Jan Feb Mar Apr May Jun
Jul Aug Sep Oct Nov Dec);
my #day_names = qw(Sun Mon Tue Wed Thu Fri Sat Sun);
return sprintf('%s, %02u %s %04u %02u:%02u:%02u +0000',
$day_names[$time[6]], $time[3], $month_names[$time[4]],
$time[5] + 1900, $time[2], $time[1], $time[0]);
}
By hard-coding the timezone to +0000 you avoid all of the above mentioned problems, while still being perfectly standards compliant, leave alone faster. Go with that solution, when performance could be an issue for you. Go with the first solution, when your users complain about the software reporting the "wrong" timezone.