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"
Related
I want to implement a piece of code that converts a datetime object like ~U[2022-06-07 18:37:16.842920Z] to a format like Tue, 7 Jun 2022 18:37:16 GMT. I do not want to use the Calendar.DateTime.Format.httpdate since our codebase already uses DateTime.
I need it to send in API headers with RFC2616 format. Any help is appreciated.
Elixir 1.11.0 introduced Calendar.strftime/3 that is what you need. Please note that DateTime and Calendar are different built-in modules that serve different purposes. There should be no problem in using them combined.
~U[2022-06-07 18:37:16.842920Z]
|> DateTime.shift_zone!("Etc/UTC")
|> Calendar.strftime("%a, %-d %b %Y %X GMT")
# => "Tue, 7 Jun 2022 18:37:16 GMT"
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 get the start date of my calendar like this:
var date_start = $('#calendar').fullCalendar('getView').start
with .toDate() I can see this result in chrome console:
Mon Nov 09 2015 01:00:00 GMT+0100 (ora solare Europa occidentale)
I need to display this result:
Mon Nov 09 2015 00:00:00
I also want get the end of the day, should be this:
Tue Nov 10 2015 00:00:00
How I can achieve this result?
toDate gives you back a JavaScript Date object. Any output string is therefore based on the specific implementation of Date.toString. If you want specific output, you should instead format using moment's format function.
date_start.format("ddd MMM DD YYYY HH:mm:ss")
However, this will return 01:00 and you asked for 00:00. It's not clear if you are asking for the local start-of-day, or if you're asking for the equivalent UTC value.
If you wanted the local start of the day:
date_start.clone().startOf('day').format("ddd MMM DD YYYY HH:mm:ss")
If you wanted the equivalent UTC value:
date_start.clone().utc().format("ddd MMM DD YYYY HH:mm:ss")
Cloning is important, as moment objects are mutable. If you don't clone, then you'll be manipulating the original moment, which could have unintended side effects in fullcalendar. You can use either the clone function shown above, or you can wrap it in the moment function, as in moment(date_start)... Both do the same thing.
For the ending value, looks like you want the start of the next day, so do this:
date_start.clone().startOf('day').add(1, 'day').format("ddd MMM DD YYYY HH:mm:ss")
Or:
date_start.clone().utc().add(1, 'day').format("ddd MMM DD YYYY HH:mm:ss")
Again, pick the one that corresponds to your usage scenario.
FYI - you seem to be asking for UTC, but in the vast majority of cases, local time is more relevant when displaying a calendar such as fullcalendar to a user.
I am having trouble with the momentjs library
the line
moment("Mon Oct 14 01:00:00 GMT 2013") parses correctly
but the line
moment("Mon Oct 14 01:00:00 BST 2013") throws an invalid date
I have tried building a format string but the zz format which is what I think I need is deprecated, is there a way to make it skip the BST/GMT bit completely as I am only interested in the date
Thanks in advance.
Time zone abbreviations aren't unique, so they cannot be parsed. You can ignore it by putting any non-format character as a placeholder:
moment("Mon Oct 14 01:00:00 BST 2013","ddd MMM DD HH:mm:ss ? YYYY")
But you should be aware that by ignoring it, you'll be assuming the local time zone of the computer where the code is running. Set your computer for another time zone and call .format() on this and you'll see what I mean.
Perhaps you don't care about time zones and just want to reformat this to something else. That's fine, but what if you provide a date that's invalid because of a daylight saving time transition in the computer's local time zone? Your browser will either skip backward or forward depending on which browser your running. To avoid that, you should work in UTC instead of in the local time. Even though your input value is from some other time zone entirely, working in UTC will ensure it doesn't get mangled.
moment.utc("Mon Oct 14 01:00:00 BST 2013","ddd MMM DD HH:mm:ss ? YYYY")
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. :)