I am facing an issue with setting time on page properties on cq:Page. The time being set into the JCR is getting converted to the timezone that is set in author’s machine. For example: time being set when author is in India is saved as +5:30 while in NY it is being set with -4:00 offset. Is there any way this can be fixed ?
Thanks !
I don't think you want to change this, unless I misunderstood the issue. Time is linear, so at any given point in time, there are as many possible ways to express the time as there are valid time zones. Anyone who views that page information through the application (not directly viewing the JCR) should see that timestamp converted to their local system time.
Related
I use ZingChart to show data as a chart. In the char, I show the data following a time which I get from the server. ZingChart is set as default to follow client time.
I found we can set time zone in a chart only as integer value. However, some time zone are UTC+10:30, UTC+04:30...
So how can we set time zone to ZingChart showing correct time? And if that day has Daylight Saving Time, how should I correct it.
JSON scripts
Unfortunately it appears that ZingChart only supports whole-hour time zone offsets. Not only does this not account for time zones with fixed fractional-hour offsets, but it also doesn't properly account for time zones that use daylight saving time.
The example in the documentation says:
... For example, to set the timezone to Pacific Time, you would add: "timezone":-8.
This is incorrect, as Pacific time is only at UTC-8 during standard time. When it's in daylight time, it uses UTC-7.
This is a common mistake. See "Time Zone != Offset" in the timezone tag wiki. My recommendation to the ZingChart developers would be:
Anywhere you support timezone:-8 you should also support fractional hour offsets such as timezone:5.5 or timezone:8.75.
You should also support named time zone identifiers such as "America/Los_Angeles". To make them work, you'll need to provide a function that the developer can hook into. Don't try to implement the function directly, as there are several libraries already available for this. For example, a developer might combine ZingChart with moment-timezone by writing something like:
zingchart.fnTZOffset = function(timestamp, timeZone) {
return moment(timestamp).tz(timeZone).utcOffset() / 60;
}
ZingChart would invoke this function when timezone was a string and would apply the resulting offset to the specific data point.
Without support from ZingChart, there's not much you can do to properly support time zones.
One other solution to the Daylight Savings time issue some ZingChart users have mentioned in the past is MomentJS. http://momentjs.com
We have due dates set on most of our assignments to 11:55pm. We just noticed that all of our due dates changed to 7:55pm on all assignments (the dates stayed the same, just the time changed). This happened in all of our courses, so it is not isolated to a single course.
So why the four hour change? I double checked the server time and that is correct, my profile time is set to be correct as well. So any idea how or why this could be happening? We obviously don't want it to happen.
We are using Moodle 2.8.1
I am working on a simple application that I need to be run as a service and report gps position every 3 minutes. I already have a working example based on the tutorial, but still have the followin doubts.
The starting of the service GPS1.Start(5*60*1000, 0)
Says first parameter is time lapse, and 2nd parameter is distance difference, How is determined, based on prior position ?
If I want to do what I stated before and I am scheduling / starting service every 3 minutes, this means I will need to ask a GPS1.Start(0,0) to get latest fix? what would be the gain to use the parameters?
I trying in a NexusOne and the Time object comes with local time, I have to do this to make it UTC but this is a tweak to the code. Is this a standard or could It change based on Phone model ? hora=DateTime.Date(Location1.Time + 6*DateTime.TicksPerHour)
thanks
If you are only interested in a single fix each time then you should pass 0, 0. These values affect the frequency of subsequent events.
You can find the time zone with the code posted here: GetTimeZone
I can get a list of time zones with [NSTimeZone knownTimeZoneNames], but that only gives the time zone IDs which include one or two cities in each time zone.
The Date & Time settings has a great list of cities and I have seen a few other apps that have the same if not similar lookup lists.
Where do these lists come from?
I do need to relate a picked city to its time zone like Date & Time does.
Only 2? On 3.1 the [NSTimeZone knownTimeZoneNames] returns an array of 401 elements, and there are much less than 200 timezones on the Earth.
I'm pretty sure "other apps" use +knownTimeZoneNames as well, since this is the only public method returning such list. Please make sure your code is correct, though.
Settings.app uses the private CPCity API from the private AppSupport.framework. It does have San Francisco, but it's private.
You need to create your own database (the data can be copied from /System/Library/PrivateFrameworks/AppSupport.framework/all_cities_adj.plist).
What you are asking for is commonly referred to as the Olson database. See for instance this Wikipedia page. The public domain Zone.tab file contains all of the timezones. You can find a zones.tab file in the zoneinfo directory of the libical distribution.
I know it might be a late answer, but just in case someone else stumbles on it like I did the other day. I just open sourced a library that does exactly this. It is available as a CocoaPod and you can find it here:
https://github.com/gligorkot/TimeZonePicker
Also, thanks for all the replies above, they helped me in finding the correct cities database that is used for the Settings app.
I have a few places in the code where I need to use the TimeZone. I can get the timezone name using DateTime::TimeZone. Is it reasonable to put the timezone name in a constant? Or should it be in a variable?
If the value can change, use a variable, of it is guaranteed to stay the same, use a constant.
For a timezone, the chance it will change is not big, but it is also not 0. The user can change the timezone and it would be nice if the program behaves accordingly.
I vote for variable. You could end up with different users in different timezones working with your application, even if you doubt that could ever happen. It happened to me a couple of years ago.
Look at where the timezone is coming from. Is it the timezone of a city? Make it constant. Is it the timezone of the user? Make it variable - we users travel all the time, and we reset the timezone on our laptops so that Outlook scheduling will work correctly at the new location.