Just now ("Sun Jun 9 17:19:24 MDT 2013"), I ran this command:
> date -d "first Sunday next month"
Tue Jul 9 00:00:00 MDT 2013
which is neither a Sunday, and isn't even the first Tuesday of next month:
How is date -d interpreting my input?
Is there a verbose option to date (or even "date -d") that shows
how my input is interpreted? It's not -v, and "man date" doesn't
show a verbose option.
I realize there's probably some library handling "date -d". Where
can I find that library and its documentation, limitations, etc?
I realize no program can handle every possible format, but it's
unnerving to see "date -d" give the wrong answer. I'd have much
preferred "date: can not parse 'first Sunday next month'" to the
wrong answer.
EDIT: running this on fedora 11 core:
> date --version
date (GNU coreutils) 7.2
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
GNU date options :
-d, --date=string display time described by string, not now. It is a human readable format such as "next Thursday" or "1 month ago". A date string may contain items indicating calendar date, time of day, time zone, day of week, relative time, relative date, and numbers. This is also known as relative GNU date formats.[1] Here are a few examples of relative date:
date --date="1 days ago"
date --date="yesterday"
date --date='10 month ago'
date --date='2 hour ago'
date --date='Second Friday'
i bluntly copied this from the wiki. : http://en.wikipedia.org/wiki/Date_(Unix)
this date -d is stupid -- gave me 16th July as the next first sunday next month
Kaizen ~ $ date -d "first Sunday next month"
+ date -d 'first Sunday next month'
Tue Jul 16 00:00:00 IST 2013
it seems that the string has keywords that are anded and then results given.... Sunday + next month... after todays date ie 10th (in June) in the next month (July) is 16th of July.
if i did use Monday here instead of Sunday , i get 17th July as answer.
Kaizen ~ $ date -d "next month monday"
+ date -d 'next month monday'
Wed Jul 10 00:00:00 IST 2013
like wise if i use "next month monday" then it will go to the next month and look for monday from todays date ie 10th is the result.
does this help ?
Also it's super not portable and dosen't work alike on all servers ... dont know about you but I would stay away from it for programing purposes.
also there was a super user question of similar nature : http://superuser.com/questions/572088/unix-date-command-not-working-for-few-servers you can check that out too
How is date -d interpreting my input?
Via this Bison grammar that's part of Gnulib, on which date (and indeed much of the coreutils package) depends. My days of writing grammars are long gone, but the relative date/time parsing "fun" seems to start around line 892.
Is there a verbose option to date (or even "date -d") that shows how my input is interpreted?
The current version of GNU date as I write this (v8.28) does have a debug mode:
$ date --debug -d "first Sunday next month"
date: parsed day part: next/first Sun (day ordinal=1 number=0)
date: parsed relative part: +1 month(s)
date: input timezone: system default
date: warning: using midnight as starting time: 00:00:00
date: new start date: 'next/first Sun' is '(Y-M-D) 2019-02-03 00:00:00'
date: starting date/time: '(Y-M-D) 2019-02-03 00:00:00'
date: warning: when adding relative months/years, it is recommended to specify the 15th of the months
date: after date adjustment (+0 years, +1 months, +0 days),
date: new date/time = '(Y-M-D) 2019-03-03 00:00:00'
date: '(Y-M-D) 2019-03-03 00:00:00' = 1551542400 epoch-seconds
date: timezone: system default
date: final: 1551542400.000000000 (epoch-seconds)
date: final: (Y-M-D) 2019-03-02 16:00:00 (UTC)
date: final: (Y-M-D) 2019-03-03 00:00:00 (UTC+08)
Sun Mar 3 00:00:00 +08 2019
As you can see, it went left-to-right;
* "first Sunday" resolves forward to the first Sunday of Feb 2019 (2019-Feb-03), then
* "next month" adds one month (2019-Mar-03), which just happens to be a Sunday too, since it's not a leap year.
I realize there's probably some library handling "date -d". Where can I find that library and its documentation, limitations, etc?
Gnulib, as mentioned above. Also, the Date input formats section of the coreutils manual is worth reading in detail.
I realize no program can handle every possible format, but it's unnerving to see "date -d" give the wrong answer. I'd have much preferred "date: can not parse 'first Sunday next month'" to the wrong answer.
I'm sure the authors of the parse_datetime routine would agree. Sadly, your date phrasing seems like it just happens to match some grouping of the existing grammar rules, so date dutifully does the necessary calculation...and comes up with the wrong answer.
Perhaps a polite bug report to the Gnulib bugs mailing list (bug-gnulib#gnu.org) might set some gears turning.
Oh, and you probably already figured it out, but date -d "first Sunday" gets you the right result...as long as you're past the current month's first Sunday. :)
Related
I tried to get the start date of a specific week in Moment.js from the week number and year by doing moment().year(...).isoWeek(...).startOf('isoWeek')
But It seems that this function is not always returning the correct date.
For example when I live in England and a week always starts on a monday.
We should get 31 Dec 2018 when we ask for the first day of week 1, 2019.
This wasn't the case on 31 Dec 2018 as the result I received was 30 Dec 2019 as the begin date of week 1, 2019. See example
I think I found the solution I was looking for
moment()
.isoWeekYear(year)
.isoWeek(week)
.startOf('week')
Please note that, as i18n section of the docs states:
By default, Moment.js comes with English (United States) locale strings. If you need other locales, you can load them into Moment.js for later use.
So if you want to use en-gb locale you have explicitly load it (in the browser, you can use en-gb.js file or moment-with-locales.js and then set locale using moment.locale('en-gb')).
You don't have to use year() setter, because it sets the year to 2019 and moment().year(2019).isoWeek(1) gives you the first isoweek of the 2020. You can create a moment object for a given year using moment({y: year}) instead.
You have to use week() instead of isoWeek if you want locale dependent results:
Because different locales define week of year numbering differently, Moment.js added moment#week to get/set the localized week of the year.
The week of the year varies depending on which day is the first day of the week (Sunday, Monday, etc), and which week is the first week of the year.
Here a full code sample:
// Set locale to British English
moment.locale('en-gb');
var year = 2019;
var firstMonday = moment({y: year}) // get first day of the given year
.week(1) // get the first week according locale
.startOf('week'); // get the first day of the week according locale
// Show result
console.log(firstMonday.format());
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.23.0/moment-with-locales.min.js"></script>
You can use format() to display the value of a moment object.
I am trying to understanding the date reading of ISO 8601 format and cant find a good doc to read.
If I am getting time in my code like this "2018-08-18T00:00:00+1000", is this local time or UTC time?
and when I convert it using Convert.ToDateTime("2018-08-18T00:00:00+1000"), I get the following date time {8/17/2018 7:00:00 AM}. I am not sure if that is UTC datetime or local?
What is the math behind "2018-08-18T00:00:00+1000" getting converted to {8/17/2018 7:00:00 AM}, I cant get my head around this.
You are asking for the math behind 2018-08-18T00:00:00+1000 being shown as 8/17/2018 7:00:00 AM.
First of all 8/17/2018 7:00:00 AM is just another format to display the date and time. Converted to an ISO 8601 string it would look like this: 2018-08-17T07:00:00.
+1000 at the end of the 2018-08-18T00:00:00+1000 representation is a timezone offset. You could read that string as August 18, 2018 in UTC plus ten hours. So it would be the same as 2018-08-18T10:00:00Z.
So we have a UTC date of August 18, 2018 10 AM, which is shown as a locale date of August 17, 2018 7 AM. That would mean that you are in a timezone which is 27 hours behind UTC.
A timezone behing more than 12 hours before (or 14 after) UTC does not exist (as far as I'm aware of). Therefore I assume that you have a typo in your example. Another reason could be a totally broken date parser.
But I still hope you got the math behind the conversion.
I have a date object formatted to isotime. I'm using the |date filter to nicely format this in my template, but it incorrectly changing the time.
This Code...
<td>[[ user.last_online | date:'dd MMM yyyy - hh:mm a' ]]</td>
<td>[[ user.last_online ]]</td>
Results in this...
Now I know that the 1 hour difference is because of the Timezone, this is what I'm expecting. The Minutes however is incorrect.
In the first row, 13 minutes gets added when the filter is applied.
In the second row, 5 minutes gets added.
Not only are these two values wrong, but they are also inconsistent.
If you check ISO8601, you can see the correct time stamp format is
yyyy-MM-ddTHH:mm:ss.SSSZ
The milliseconds should consists of 3 digits. I did a simple test and you can see after correcting the milliseconds part, the dates will be rendered correctly.
{{"2013-08-09T15:36:31.764546+02:00" | date:'dd MMM yyyy - hh:mm a'}}<br />
{{"2013-08-09T15:34:14.318753+02:00" | date:'dd MMM yyyy - hh:mm a'}}<br />
{{"2013-08-09T15:36:31.764+02:00" | date:'dd MMM yyyy - hh:mm a'}}<br />
{{"2013-08-09T15:34:14.318+02:00" | date:'dd MMM yyyy - hh:mm a'}}<br />
The result is
09 Aug 2013 - 09:49 AM
09 Aug 2013 - 09:39 AM
09 Aug 2013 - 09:36 AM
09 Aug 2013 - 09:34 AM
Demo
Update
Python's datetime.isoformat() return the time with microseconds 0 <= microsecond < 1000000. Angularjs doesn't like, though this format is correct according to ISO8601, since ISO8601 only requires one or more digits representing a decimal fraction of a second
So I guess you can use strftime to format it.
I think the value of user.last_online is incorrect or has a bad format. If you check ISO8601, you can see the correct time stamp format is:
yyyy-MM-ddTHH:mm:ss.SSSZ
My plunker
Your dates are correctly formatted. ISO8601 doesn't actually require any particular number of decimals. There could be anywhere from zero to 7 decimals or more. If you look at an actual copy of the ISO8601 spec, section 4.2.2.4 says the following:
... with as many digits as necessary following the decimal sign ...
There are a few older browsers where this mattered when passed directly to the new Date() constructor, but AFAIK those were consider bugs and were fixed.
You are experiencing a bug in AngularJS, which was fixed in version 1.1.5. You can find it referenced in their change log as follows:
date filter: correctly format dates with more than 3 sub-second digits (4f2e3606)
I am trying to convert boost::posix_time::ptime from GMT to UTC.
I went on Boost web site, and most of the examples are for US time zone, but I need the GMT one.
All I need is the right parameters to put in boost::date_time::local_adjustor
Thanks.
Ok, assuming this is WET your string should be (Summertime is from last Sunday in April, 2:00 until last Sunday in October, 3:00):
"WET-0WEST,M4.5.0/02:00:00,M10.5.0/03:00:00"
I have a shell script that I want to get the date and time 30 minutes ago in GMT.
I have this working great for full hours, but partial hours don't seem to work:
1 hour ago
TZ=GMT+1 date +%Y-%m-%d" "%H:%M:%S
2010-01-08 17:43:57
2 hours ago
TZ=GMT+2 date +%Y-%m-%d" "%H:%M:%S
2010-01-08 16:44:07
1/2 hour ago
TZ=GMT+.5 date +%Y-%m-%d" "%H:%M:%S
2010-01-08 18:44:38
tried lots of combinations of 0.5 1.5, no partial hours seem to work, which is weird because there are some timezones that are not full offset of an hour.
any suggestions?
cant use perl or ruby needs to be regular shell or mysql call.
date -u --date="-30 minutes"
You can also do this:
TZ='UTC+0:30' date
/usr/bin/env TZ='GMT' date -d '-30 minutes'
This is with the version of the date command that's part of the GNU coreutils. I don't know if it works for other versions of the date program.