I'm building few dashboards in Apache superset. All my available timestamp fields are in UTC timezone. (for example fields are, class_start_time & class_end_time).
I want that in the timezone the dashboard is opened all the timestamp fields will be automatically converted.
For example, I'm opening dashboard in Norway , so the UTC data should be converted to CET timezone of Norway.
I have tried to add some value here in Hours offset but its not working.
Can you please guide how we can achieve this.?
Just for reference :
In Kibana dashboards (ELK stack) have feature to automatically convert the timezone into which it is being opened. So I need same thing in Superset.
Normally you would be able to set this with environment variables when you start the program or container. In Apache Superset, this is not possible. There is an ongoing discussion on Github about this issue. One GitHub user posts the problem and workaround, which is far from workable:
Daylight savings causes issues where users have to update datasource
timezone offset for each datasource twice per year.
So the only thing you can do is update the hours offset twice a year. To make matters even worse, if you use Postgresql, this may not even be possible due to a bug as described here.
Related
When I Insert timestamp into Postgres table in EST (2019-02-21 05:37:46) and in Postgresql table is stores in IST (2019-02-21 16:07:46). I want time to be stored only in EST. Can anyone help me to fix this issue?
In postgres, you can change the default format mask for datetimes using the set n postgres, you can change the default format mask for datetimes using the set datestyle
for more details follow this link
also refer this link
To my knowledge, there is no setting in PostgreSQL that would trim seconds from timestamp literals by default
In general you should handle all datetimes in UTC, because these are absolute timestamps that are always correct. Even if you are only going to have users in the EST time zone use your website, the EST time zone has daylight saving time (DST) in the summer, so you could get buggy behaviour when the time jumps (especially since there is an overlap of one hour when the clock goes back). This means:
Your code should use UTC timestamps to make calculations and pass around
Your database should store UTC datetime (which PostgreSQL does anyway).
You should only transform to a local time zone when presenting the data to the user. This is default behaviour in Django:
USE_TZ = True by default
TIME_ZONE = "America/New_York" to set default time zone, which will take into account DST
So when you're saving a time-aware datetime to the database (in EST say), the database stores it as UTC. When you fetch and display it, Django will show it in the current time zone of the user (EST in your case). When you query the database directly using a tool, PostgreSQL gives back the UTC, correct datetime, but your shell or tool might display it in the local time zone. You can format your query to use a different time zone using the links posted by #c.grey in the other answer.
Read up on the details here
Recently we migrated 2013 sites to office 365 using metalogix tool, in one of the site Task list is migrated with all content but the date which is displaying in due date column is one day ahead of the date in source site
Ex: due date is 02/03/2017 in source but in target it is 03/03/2017
are there any teams which faced similar kind of issue??
what might be the fix for this issue??
You have migrated your SP 2013 sites to O365. Your SP 2013 uses your local timezone and O365 uses its timezone. When you migrate SP2013 to O365, it changes the DateTime value(in your local timezone) to O365 timezone. Thats the reason for 1 day ahead.
We're experiencing a similar issue now migrating from a SP 2007 on prem to a SP 2013 on prem. In one list, the dates are "1/01/1900" but the migration fails with Metalogix reporting that "1899-12-31T15:00:00.0000000Z" is an invalid date for those exact fields.
Not sure why at the moment as both servers appear to be set in the same time zone with the same locale.
UPDATE: This is happening on our servers because the SP2007 is set to GMT time whereas the SP2013 is set to UTC time. A default time value in a date/time field entered when the user cannot enter a time component is 12am. So during the migration daylight savings is/isn't taken into account on one of the servers. We've pushed those particular records one day ahead -> when they get migrated they fall back to 01/01/1900 11:00pm -> all we care about is the date so they come across.
From Servicenow WSDL, am getting data in some time-zone format.
In Servicenow, there is a option to change the users timezone and get the data as expected . But if we change the timezone in servicenow, it didnt affect for the data which comes through servicenow-WSDL.
How to convert the timezone for the data get through WSDL. Is there any way available in servicenow to automatically convert ? or any idea to develope our own script/code to do the same?
Thanks for your time.
Something to keep in mind when working with SN web services is that by default all time values will come back in UTC time. You can ask for "Display Values" by setting request parameter "displayValue" to either "true" to get back only display values or "all" to get back both display values and direct values.
The Display value for a time field is resolved according to: user timezone preference, then by system timezone.
For example, you could get the WSDL with this request:
https://<instance>.service-now.com/incident.do?WSDL&displayValue=true
and then also include the &displayValue=true on the SOAP request:
https://<instance>.service-now.com/incident.do?SOAP&displayValue=true
Here's a link to the product docs with more info about getting back display values through SOAP: http://wiki.servicenow.com/?title=Direct_Web_Services#Return_Display_Value_for_Reference_Variables
Note the same rules apply when using the REST interface as well, but the parameter is "sysparm_display_value" (http://wiki.servicenow.com/index.php?title=Table_API).
Hope this helps.
I've started a django project that will include an analytics app. I want that app to use either couchDB or mongoDB for storing data.
The initial idea was (since the client already is using Google Analytics) to once a day/week/month grab data from GA, and store store it locally as values in database. Which would ultimately build a database of entries - one entry per user per month - with summed values like
{"date":"11.2011""clicks": 21, "pageviews": 40, "n": n},
for premium users there could be one entry per user per week or even day.
The question would be:
grab analytics from GA, do a sum entries for clicks, visits etc.
or
store clicks and whatever values locally and once a month do sums for display ?
Lukasz, unless Google Analytics has really relaxed their privacy levels, you're not going to be able to access user-level records (but check out the answer here: Django saving the whole request for statistics, whats available?)
Right, old question but I've just finished the project so I'll just write what I did.
Since I didn't need concurrency and wanted more speed approach, I found that mongodb is better for that.
The final document schema that I've used is
{'date': '11.2009', 'pageviews': 40, 'clicks': 13, 'otherdata': 'that i can use as filters'}
The scope of my local analytics is monthly, so I create one entry in mongdb per user per month, and update it each day. As said just now, I update data daily, and store only summaries and averages of those.
What else. Re: Jamie's answer... The system is using GA events, so I've got access to all data that i need.
Hope someone may find it interesting.
cheers and thanks for ideas !
When I execute getDefault() on a java.util.TimeZone object created from ColdFusion 9 I am getting "Pakistan Time". We are in the eastern timezone and our server (Windows 2003) is reporting proper timezone. Where would ColdFusions JVM be getting this timezone?
TimeZone: Pakistan Time (Asia/Karachi)
try this: http://troymurray.blogspot.com/2007/12/coldfusion-timezone-change.html(deleted)
Content retrieved from Google's cache:
ColdFusion Timezone Change
So I've been working on a component to accept data from whatever and insert it into our Oracle database, no big deal. But, I need to do this with date and times, which gets really sticky with Oracle. I noticed however that my ColdFusion function Now() was returning the wrong time, about 5 hours off, which corresponds to my timezone (-5).
I looked all through the ColdFusion Admin but wasn't able to find anywhere to specify this. I then seem to remember that when I setup this server, and installed ColdFusion on it, that I had the wrong timezone set and somehow that must have been saved. Since ColdFusion relies on Java I needed to change the time zone with the Java Virtual Machine (JVM) that ColdFusion runs. Here is how I did it:
First, find the correct timezone ID for your location. I found mine by going here.
Login to the ColdFusion Admin
Under Server Settings go to Java and JVM
Locate the JVM Arguments textarea
Add a space after the last character, then "-Duser.timezone=" and then your timezone ID.
Click the "Submit Changes" button
Restart the "ColdFusion 8 Application Server" service
Verify your time shows correctly now.