Another Google Chart related question this time I like to edit the onrollover annotation. At the moment it shows the function which i like to remove and i like to show a % , in this case 96.40%
Oh and I notice this Google Start doesn't plot / start and ends with the right month. It starts in March en ends in July (but should be Feb - Jun)
data.addRows([
[new Date(2017 ,02) ,100.00,'100.00'],[new Date(2017 ,03) ,100.00,'100.00'],[new Date(2017 ,04) ,100.00,'100.00'],[new Date(2017 ,05) ,100.00,'100.00'],[new Date(2017 ,06) ,87.50,'87.50']
]);
Related
I am trying to retrieve current date time in RFC1123 date format in XSLT.
has anybody tried this using XSL2.0?
I have seen code for converting various date times based on zone in XSLT2.0 and to format in specific date time format such yyyy/mm/dd or YYYY:MM:DDTHH:MM:SS.0Z, but couldnt find a way to format it to show like this
Tue, 09 Jul 2019 20:34:29 GMT
concat(date:add('1970-01-01T00:00:00',concat('PT',floor(dp:time-value() div 1000),'S')),':',dp:time-value() mod 1000)
This returns in GMT format like this 2019-07-09T21:01:26:547
How to format it for - Tue, 09 Jul 2019 20:34:29 GMT using XSLT2.0?
Use current-dateTime() to get the current date and time and then use format-dateTime to format it as needed, see the spec https://www.w3.org/TR/xslt20/#function-format-dateTime on details: a picture string
'[FNn,*-3], [D01] [MNn] [H01]:[m01]:[s01] [z]'
on my machine in German summer time gives
format-dateTime(current-dateTime(), '[FNn,*-3], [D01] [MNn] [H01]:[m01]:[s01] [z]')
as
Wed, 10 July 12:01:13 GMT+02:00
This is meant as an example on the use of format-dateTime, I haven't checked the exact details of the RFC you cited to try to implement the exact requirements.
Thanks for quick reply, your solution worked using Altova XML Spy, but unfortunately it didnt worked for me in Datapower using XSLT2.0, Not sure what was wrong, may be some issue with DP firmware version.
just for other users to make this post more helpful. I tried below 2 options which didnt work for me, but might be useful for others.
using XSLT
<xsl:value-of select="java:java.time.format.DateTimeFormatter.RFC_1123_DATE_TIME.format(ZonedDateTime.now(ZoneOffset.UTC))"></xsl:value-of>
<xsl:value-of select="format-dateTime(current-dateTime(), '[FNn,*-3], [D01] [MNn] [H01]:[m01]:[s01] [z]')"/>
So I used Gateway script to get same date format which I was looking for and stored in context variable using below
var dateNeeded = new Date()).toUTCString(); //Thu, 11 Jul 2019 21:08:12 GMT
I'm writing a custom function to return financial quotes obtained from Yahoo Finance to a Google Sheets spreadsheet (the built-in GoogleFinance() won't cut it for various reasons), and I'm having problems to return a Date object containing the date and time of the quote. https://developers.google.com/apps-script/guides/sheets/functions says that "Times and dates in Sheets become Date objects in Apps Script. If the spreadsheet and the script use different time zones (a rare problem), the custom function will need to compensate", but it's not clear how.
First of all, the timezone of my browser is "asia/hong_kong", i.e. GMT+0800 (HKT). It turns out that the script somehow knows that, because when I format a Date object built with d = new Date(2016,5,24,0,0,0,0) with d.toString() I get "Wed Jun 24 2016 00:00:00 GMT+0800 (HKT)". This is weird, because SpreadsheetApp.getActiveSpreadsheet().getSpreadsheetTimeZone() actually returns "America/Los_Angeles", indicating that the server is on the West Coast of the US: so why does the method toString(), which is run on the server side, format the date according to the Hong Kong time? This sounds like a bug to me.
Anyway, the biggest problem I'm having is that when the custom function returns the date object to the spreadsheet, if I format the cell with Format -> Number -> Date time, what I see displayed is "23/06/2016 09:00:00", i.e. the date and time on the US West Coast when the Hong Kong date and time are the ones I specified through the parameters passed to the constructor (corresponding to Wed Jun 24 2016 00:00:00).
Then I tried to build the Date object with new Date(Date.UTC(2016,5,24,0,0,0,0)), but (predictably enough) now the spreadsheet displays "23/06/2016 17:00:00", which is the date and time on the West Coast when the UTC date and time are the ones I specified.
So, how do I get a Date object that, once returned to the spreadsheet, shows exactly the same date and time I used to build it? I tried to change the spreadsheet's timezone to UTC using ss.setSpreadsheetTimeZone("Etc/UTC"), but then unfortunately the script returns the error "You do not have permission to call setSpreadsheetTimeZone"...
This is the kludgy solution I managed to write (but I hope there is a better way):
// hours and minutes contain values obtained from the text quote; the date is in the string variable:
// date_str = "05/24/2016";
var tz = SpreadsheetApp.getActiveSpreadsheet().getSpreadsheetTimeZone(); // this returns the TZ of the server, "America/Los_Angeles"
var ums = Date.parse(date_str+" UTC");
var offset = Date.parse(Utilities.formatDate(new Date(ums), tz, "MM/dd/yyyy HH:mm:ss") + " UTC") - ums; // time in LA - UTC time in ms
var d = new Date(Date.parse(date_str));
d = new Date(Date.UTC(d.getFullYear(),d.getMonth(),d.getDate(),hours,minutes,d.getSeconds())-offset);
return d;
I have an agenda that I want to export as an icalendar file.
I do not use properties and org-mode export determines summary and description automatically from the headers and bodys.
The entries were like this one
* <2015-05-19 Tue 13:45-15:15> My entry
Sometimes, this worked properly. I got an entry with summary "My entry" at the time specified by the timestamp. Now, the entry is correctly put at the time, but the timestamp is included into the summary and therefore I can see it in my calendar application.
I have tried, permuting the order of timestamp and header, but the best i have got is by putting the timestamp in the body, as in the following entry
* My entry
<2015-05-19 Tue 13:45-15:15>
Now, the tismestamp is no longer in the summary, but in the description of the event.
I have tried going through the org-mode options but I have not find any possible explanation of this changing.
Can anybody help me in using timestamp to correctly put the event, but avoiding to include it into the exported event?
I'm having the same problem. I found that you can add properties to each item to specify what should be in the summary, like so:
* <2015-05-19 Tue 13:45-15:15> My entry
:PROPERTIES:
:SUMMARY: My entry
:END:
(You can also add LOCATION and DESCRIPTION properties)
But that's pretty annoying.
I've run across an issue with date-time conventions in a file served via OPeNDAP. In particular this problem arises from the GrADS DODS Server (GDS). The GDS can serve files via reading a data descriptor (ascii file) that contains the specifics of the binary file (GDS is not limited to netCDF as input). The data descriptor file defines the start time and increment. Somehow, GDS converts this to a convention (?) of "days since 1-1-1 00:00:00". I've discovered an interesting issue with this.
As an example, the data served at http://apdrc.soest.hawaii.edu:80/dods/public_data/satellite_product/ASCAT/daily are defined to start on 03 March 2009. The OPeNDAP info page has the following for time:
time: Array of 64 bit Reals [time = 0..1141]
grads_dim: "t"
grads_mapping: "linear"
grads_size: "1142"
grads_min: "00z03mar2009"
grads_step: "1dy"
units: "days since 1-1-1 00:00:0.0"
long_name: "time"
minimum: "00z03mar2009"
maximum: "00z17apr2012"
resolution: 1.0
So it correctly gets the first time value. I've tested this in several client tools, including GrADS, Ferret, panoply, and IDV; all correctly recognize the first time value as March 3, 2009.
The trouble arises from the OPeNDAP time of "days since 1-1-1", which gets returned as 733470 (try an ncdump on the above file). As far as I can tell, this is actually March 5th, 2009. The result here is tools like Matlab and EDC get the initial date as March 5.
I'm wondering if anyone can shed some light on this? Thanks in advance,
Jim
Unless the other tools use the 'minimum' attribute somehow, I cant see how the first time element can be 03-Mar-2009.
However, March 5th, 2009 checks out if use the information in the units field:
Here's what I see in MATLAB:
>> ncdisp('http://apdrc.soest.hawaii.edu:80/dods/public_data/satellite_product/ASCAT/daily','time')
Source:
http://apdrc.soest.hawaii.edu:80/dods/public_data/satellite_product/ASCAT/daily
Format:
64bit
Dimensions:
time = 1142
Variables:
time
Size: 1142x1
Dimensions: time
Datatype: double
Attributes:
grads_dim = 't'
grads_mapping = 'linear'
grads_size = '1142'
grads_min = '00z03mar2009'
grads_step = '1dy'
units = 'days since 1-1-1 00:00:0.0'
long_name = 'time'
minimum = '00z03mar2009'
maximum = '00z17apr2012'
resolution = 1
Lets see what MATLAB's reference date is for numbers:
matlabRefDate = datestr(0)
matlabRefDate =
00-Jan-0000
The date number for this data source is since 1-1-1 so:
dataRefDate = '01-Jan-0001';
dataRefDateNum = datenum(dataRefDate)
dataRefDateNum =
367
Lets read the data and update the reference:
>> time = ncread('http://apdrc.soest.hawaii.edu:80/dods/public_data/satellite_product/ASCAT/daily','time');
>> datestr(time(1))
ans =
03-Mar-2008
>> correctedTime = time+dataRefDateNum;
>> datestr(correctedTime(1))
ans =
05-Mar-2009
I think I may have found the explanation:
From http://aa.usno.navy.mil/data/docs/JulianDate.php
The Julian date for CE 2009 March 3 00:00:00.0 UT is
JD 2454893.500000
The Julian date for CE 1 January 1 00:00:00.0 UT is
JD 1721423.500000
So the time of the ASCAT start since the year 1 origin is 733470 days. This agrees with
the GrADS/GDS accounting. The answer all comes down to reference dates. I suspect that what netCDF4 calls the "standard" calendar is this USNO version that switches from Gregorian to Julian, and this is not what matlab does.
It's probably better practice, therefore, not to reference to Jan 1, 0001 but rather something closer to present thus avoiding the potential two day difference between old and new calendars. However, if a data service is providing it (as is the case here), you're kind of stuck with it.
Eric Firing has a nice summary here:
http://matplotlib.org/api/dates_api.html
we have enabled the October 2nd 2013 breaking changes for our application yesterday, the change to the application settings is already confirmed. If I submit bid_info in the new format (with strings instead of numeric indexes) it works:
"bid_info": {
"CLICKS": 75
}
When I try to read the ad group with a request to its url later, I get a bid_info and a max_bid setting in parallel (I expected that max_bid will be removed in October 2nd-mode), but the bid_info contains the numeric index and not the expected CLICKS-string:
(...)
"adgroup_status": 3,
"bid_type": 1,
"max_bid": 75,
"bid_info": {
"1": 75
},
"ad_status": 3,
"locations": [
3
],
(...)
Any suggestions for that? Is this bug or by design? Or did something went wrong with the activation of the October 2nd changes for our application?
Bye
Tobias
Same for me but without activating october 2nd breaking changes...
It's quite strange to have number as name field and it is not allowed in languages like in c#.
It should be this kind of info:
A dictionary of values that you place on your bid
CPM={'REACH':cent_value}
CPC={'CLICKS':cent_value}
oCPM or CPA={'ACTIONS':cent_value}
I've 1, 38, 44, 55 in place of this.
Update, it's actually this:
Actions: 55
Reach: 44
Clicks: 1
Social Impressions: 38
More info: https://developers.facebook.com/docs/reference/ads-api/optimizedcpm/
https://developers.facebook.com/bugs/539767489417940?browse=external_tasks_search_results_5203fffd63da04c48847913
I actually filed a ticket against this. The Facebook bug response said it would be fixed on July 17th, however a contact at Facebook elevated this ticket after it was not fixed on July 17th, and it is now being currently worked on.
We were told it should be functional by the end of August.