In thingsboard I have a post-processing function for an server attribute update dialog.
update server attribute widget
post-processing date value
post-processing date value fails
I need to convert a text value (entered by the user in a widget) into a unix time stamp (milliseconds precision) to store it into an thingsboard attribute.
I also want do use this function to display the value in a formatted ISO date string. Something linke YYYY-MM-DD hh:mm:ss.
As I understand, the date.getMonth, getFullYear, ... functions are pretty standard for JavaScript. What do I need to do to use them in thingsboard too?
Is there a better way to convert dates?
You have to call use the new-operator to create a date-object.
See Date - JavaScript | MDN:
The only correct way to instantiate a new Date object is by using the new operator. If you simply call the Date object directly, such as now = Date(), the returned value is a string rather than a Date object.
So instead of
var date = Date(value);
it should be
var date = new Date(value);
However, there is a handy and popular javascript date-library called moment.js. Fortunately it is already bundled with Thingsboard and you can use it in widgets and those post-processing functions.
Related
I'd like to pass the Unix timestamp to a hit level eVar in DTM. I would assume I could pass some Javascript like this:
function() {
var now = new Date();
return now.getTime();
}
However, I am not sure where to pass it in DTM. Would this be passed in the "Customize Page Code" editor in the Tool Settings or somewhere else?
You can create a Data Element of type Custom Code. Name it something like current_timestamp or whatever. The code should not be wrapped in the function declaration syntax (DTM already wraps it in a function callback internally). So just put the following in the code box:
var now = new Date();
return now.getTime();
Then in your Adobe Analytics Tool Config (for global variables), or within a Page Load, Event Based, or Direct Call Rule, within the Adobe Analytics Config section. choose which eVar you want to set, and for the value, put %current_timestamp% (or whatever you named it, using % at start/end of it. You should see it show up in a dropdown as you start typing % in the value field).
Alternatively, if you want to assign the eVar in a custom code box in one of those locations, you can use the following javascript syntax e.g (assume eVar1 in example).
s.eVar1 = _satellite.getVar('current_timestamp');
Note that with this syntax, you do not wrap the data element name with %
One last note. This is client-side code, so the timestamp will be based on the user's browser's timezone settings. So for example, a visitor from the US and another visitor from China both visiting a page physically at the same time (server request at the same time), will show two different timestamps because they are in two different timezones.
This makes for some misleading data in reports, so make sure you break it down by other geo based dimensions, or do some extra math in your Data Element to convert the timestamp to a single timezone (e.g. convert it to EST). In practice, most people will pick whatever timezone their office is located in, or else what their server's timezone is set to.
I want to store dates in database as Normal Gregorian dates. However, I want to enable user view/edit them in Hijri calendar.
Now I have two problems:
Before displaying the date, convert it to Hijri (Done, using DisplayTemplates)
After user edit and submit, convert Hijri value to Gregorian. (My problem)
I now can use FormCollection and invoke a helper method to convert the received Hijri to Gregorian, but I am asking if there is some method to automatically convert the value to Gregorian, maybe something IModelBinder ??
I don't want breeze to tack on the time zone information on the server, or the client. How do I turn this off?
I have a SQL DATE field in the database- I don't want time. When working with DateTime variables in C#, I always want them set to midnight. I am overriding breeze.DataType.parseDateFromServer on the client as described here https://stackoverflow.com/a/17669486/2107571 but I seem to be still getting the adjustment on the server.
The key point here is that breeze is NOT tacking on time and timezone information. The issue is that dates automatically serialize with a time component because in javascript all dates have a time component. So even if this information is all set to all zeros, it will still be interpreted on the client as a date with a time component.
The second issue is that virtually every browser formats dates according to the browser's own timezone settings.
So the problem is either that the timezone of the server is different from that of the client or the server date is being serialized with no timezone information ( which will be interpreted by breeze as being a UTC date with a zero offset. i.e. which is very unlikely to match your local timezone.) This happens in .NET with server dates declared as DateTime as opposed to DateTime2 or DateTimeOffset.
To fix either of these you will need to replace Breeze's DataType.parseDateFromServer so that you completely ignore the timezone information coming in.
Something like:
breeze.DataType.parseDateFromServer = function (source) {
source = stripTime(source); // you will need to write the stripTime method.
return new Date(Date.parse(source));
};
If you use Moment.js, i think that you can do the following
breeze.DataType.parseDateFromServer = function (source) {
var date = moment(source);
return date.toDate();
};
A student class has a property called birthday. My web Server is in Beijing (UTC+8), and when I get data from the server in JSON format, the birthday property always reduces 8 hours to the original date, How can I correct this? I am also in Beijing and I add 8 hours to all birthday properties, but if I am in another timezone or the web server is not in Beijing then I have to add other hours manually.
On the web server, here's my code:
return Json(student);
The codes that get the data:
var studentReader= new StreamReader(Request.InputStream);
var student= JsonHelper.FromJson<Student>(studentReader.ReadToEnd());
The JsonHelper class:
public static T FromJson<T>(this string json)
{
return JsonConvert.DeserializeObject<T>(json);
}
The recommendation is that, you should store all datetime values in UTC. In the client code, you can convert it to any timezone you want.
Your JSON serialization is fine. No problems there.
You need to make sure to store all date-time values as UTC. And when you display the dates then you can make the conversion to the Timezone you need.
Here's how I usually do it:
Every time I store a DateTime I use DateTime.ToUniversalTime() to make sure the date is stored on UTC on the database.
When I need to print the date in a View I have a method that I used that takes a specific TimeZone and converts the date. See bellow for a code example.
I never rely on Client-Side zones. If I have a broad range of users from many geographical points I just make then choose their preferred timezone and store this information on their profiles (Google, Microsoft, and 37Signals all do this for their web applications just to name a few examples).
public static DateTime ToLocalTimeZone(this object date)
{
DateTime dt;
if (!DateTime.TryParse(date.ToString(), out dt))
return DateTime.UtcNow;
//Timezone string. This can be stored on web.config
//or on the user profile as well
var timeZone = "Pacific SA Standard Time";
var defaultTimeZone = TimeZoneInfo.FindSystemTimeZoneById(timeZone);
var userTime = TimeZoneInfo.ConvertTimeFromUtc(dt, defaultTimeZone);
return userTime;
}
More info on previous questions here and here
Edit: List of allowed Timezone strings here
I have an entity with a datetime object. The database time is 2012-05-07 00:00:00.000 and the data from the breeze web api call is coming as 2012-05-07T00:00:00.000, but the property holding the data is Sun May 06 2012 20:00:00 GMT-0400 (Eastern Daylight Time). Note the 4 hour difference.
According to this:
[T]he timezone of the value on the server will be carried over to the value on the client (and vice versa).
It sounds like Breeze is treating the datetime as UTC and converting it to EDT. Is Breeze doing so based on the lack of timezone information from the original date? For this specific instance I do not care about Timezone, how do I get the actual date from the database regardless of client/server timezone?
You can replace Breeze's DataType.parseDateFromServer to NOT infer any time zone info if it is not provided:
breeze.DataType.parseDateFromServer = function (source) {
return new Date(Date.parse(source));
};
However, there is another problem you are likely to run into with this. Different browsers interpret DateTime strings without a time zone offset differently... So you may still get strange results depending on the browser. If that happens you will need to add some browser detection code to the snippet above.
EDIT: The suggestion was also made that if you use Moment.js you can do the following
breeze.DataType.parseDateFromServer = function (source) {
var date = moment(source);
return date.toDate();
};