I have the 'Sign' module in an Odoo instance, that module generate a PDF certificate with the track of the user actions (sign petition sent, user signed time and location, and so).
The action date and hour are presented in UTC+0, i need to show it in UTC-5
I was checking the qweb view and the time and hour is taken from the line:
<t t-set="print_date" t-value="datetime.datetime.utcnow().strftime('%Y-%m-%d - %H:%M:%S')"/>
The function utcnow() shows the UTC universal time, i tried to change for the system time without any effect:
<t t-set="print_date" t-value="datetime.datetime.now().strftime('%Y-%m-%d - %H:%M:%S')"/>
I tried with context_timestamp:
<t t-set="print_date" t-value="context_timestamp(datetime.datetime.now()).strftime('%Y-%m-%d - %H:%M:%S')"/>
Also, the qview shows the user sign time in UTC+0 even with tz=UTC-5
<t t-set="o" t-value="o.with_context(tz='UTC-5')"/>
<td> <span t-field="log.log_date"/> </td>
How can I adjust the qview view to show the local time?
Thanks.
Related
I have a web application that is used globally.
All dates and times are stored as UTC and currently displayed as UTC with a small footer stating "All times and dates are displayed in UTC".
Obviously, most people do not know nor care about UTC, so instead I'm looking to call someDate.ToLocalTime() - which works well when the user's system is set to the local country and the browser passes that info through.
However, sometimes / often the users system is set to USA or some other default and displays the wrong time. In this instance, I can display a list of timezones available, for example:
<form id="selectTimezone" asp-controller="Account" asp-action="SetTimezone" asp-route-returnUrl="#Context.Request.Path" asp-area="" method="post" role="form">
<div class="form-group form-group-sm">
<label class="control-label">#Localiser["Timezone:"]</label>
<select name="timezoneId" class="form-control" asp-for="#TimeZoneInfo.Local.Id">
#foreach (var timeZone in TimeZoneInfo.GetSystemTimeZones())
{
<option value="#(timeZone.Id)">#timeZone.DisplayName (#timeZone.StandardName)</option>
}
</select>
<button type="submit" class="btn btn-primary btn-sm" style="margin-bottom: 0px;">#SharedLocaliser["Set Language"]</button>
</div>
</form>
My question is, and I can't find it - can I set a session wide default timezone at all?
Or will I need to store it against the user's account, then read it into a cookie and process it by adding the required number of seconds to UTC each time?
Something like:
TimeZoneInfo.ConvertTime(someDate, myTimeZoneId);
Storing all datetime data in UTC and keeping a TimeZoneId for each user in the user DB then converting UTC against the preferred (user-intended) timezone should work fine in most cases. Option for the user to change this TimeZoneId as part of user preferences will help the user change it when needed. If you want to go one step further, store a column for Timezone rule changes as well and write rule update routines for those cases alone. These articles by Dino Esposito and Jon Skeet have more meat to dwell.
On .NET core, these two articles - Cross-platform Time Zones with .NET Core and Matt's latest blog Date, Time, and Time Zone Enhancements in .NET 6 will help decide your strategy. If your application is really into precision and versatile Date, Time and Timezone based presentation, then get your hands dirty with Noda Time.
I have implemented the following process to track User ID on my website:
If the user is not yet logged in, track a pageview
Once he registers or logs in, set user id and keep setting it on every page
I have session unification turned on.
It works OK except that in the "user id" view, I see 100% of acquisition surce/medium as (direct) / (none), but in "all data" though, the utm_ parameters for the same session have been tracked correctly.
I would like to see which campaign was each given user acquired by, but because of this, I am not seeing that.
What am I doing wrong?
Ok, I found the answer in the docs eventually:
Session unification is completed during daily data processing. Processing begins at 5am each day, based on the western most timezone selected in any reporting view that is associated with the property.
Looks like I have everything set up right, just need to wait for the recalculation.
When I create or update record on sails it write this at updateAt:
updatedAt: 2014-07-06T15:00:00.000Z
but I'm in GMT+2 hours (in this season) and update are performed at 16:00.
I have the same problem with all datetime fields declared in my models.
How can I set the right timezone on Sails (or eventually Express) ?
The way I handled the problem after hours of research :
Put
process.env.TZ = 'UTC'; //whatever timezone you want
in config/bootstrap.js
I solved the problem， you should setting the MySql options file to change timezone to UTC
in the config/connections.js
setting at this
devMysqlServer: {
adapter: 'sails-mysql',
host: '127.0.0.1',
user: 'root',
password: '***',
database: '**',
timezone: 'utc'
},
Trying to solve your problem by setting the timezone on your server is a bit short-sighted. What if you move? Or someone in a different country accesses your application? The important thing is that the timestamps in your database have a timezone encoded in them, so that you can translate to the correct time on the front end. That is, if you do:
new Date('2014-07-06T15:00:00.000Z')
in your browser console, you should see it display the correct date and time for wherever you are. Sails automatically encodes this timestamp for you with the default updatedAt and createdAt fields; just make sure you always use a timezone when saving any custom timestamps to the database, and you should be fine!
The best architecture planning here, IMO, is to continue using Sails.js isoDate formatting. When you're user's load your website/app the isoDate will be converted to their client/browser timezone which is usually set at the OS level.
Here's an example you can test this out with. Open a browser console and run new Date().toISOString() and look at the time it sets. It's going to be based of off the spec for isoDate 8601 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString).
Now, change your system time to a different time zone or simply change your hour on the time and save (you shouldn't have to reload if you're using chrome console). Run your command in the console again new Date().toISOString() and you'll get an adjusted time appropriate to the time you just changed.
If you'd like to continue on proving to yourself the time Sails.js is appropriate to use, use Moment.js on an isoDate that is stored in your database (created by waterline ORM) like so moment("2016-02-05T22:36:48.800Z").fromNow() and you'll notice the time is relative to your system time.
I've come to grips with not setting a timezone at the app level (I see why the sails authors did it that way), however I've been having a rough time performing a simple date match query. I'd assume that if you create a record using the default blueprint methods (this one containing an extra datetime field over the defaults), passing in a date, that you'd be able to pass in the same date in a get query and get the same record.
For example, let's say the datetime field is called "specialdate". If I create a new record through the api with "specialdate" equaling "06-09-2014" (ignoring time), I haven't been able to run a find query in which I can pass in "06-09-2014" and get that record back. Greater than queries work fine (if I do a find for a date greater than that). I'm sure it's a timezone offset thing, but haven't been able to come up with a solution.
I want to create account in Ldap, but its need be active only in future FROM date TO date.
I use ppolicy overlay for Ldap. I try use it:
I create account and on creation time I lock it using
pwdAccountLockedTime = NOW.
I set the
pwdLockoutDuration = (FROM - NOW) in seconds
pwdMaxAge = (TO - NOW) in second.
The account was created with right pwdAccountLockedTime, but after pwdLockoutDuration duration expire, the account not unlocked automatically - why? Maybe because I set pwdAccountLockedTime manual?
I don't set pwdPolicySubentry attribute as my new entry and Ldap use pwdLockoutDuration from default configuration, not my custom pwdLockoutDuration from my entry.
From MSDN i got, once the lockout duration passes, the user is unlocked automatically.
So check whether you got Zero in lockoutTime
Add the Lockout-Time attribute to the Lockout-Duration attribute and then compare it with the current time.Zero in Lockout-Duration means the account is locked forever until the administrator unlock it.
copied from msdn site.click here
This attribute value is only reset when the account is logged onto successfully. This means that this value may be non zero, yet the account is not locked out. To accurately determine if the account is locked out, you must add the Lockout-Duration to this time and compare the result to the current time, accounting for local time zones and daylight savings time.
When I am in the month view of FullCalendar, then say I go back a few months to March and click on an event, then hit the browser 'back' button, how can I make it so that the browser knows to go back to March? Currently, it just goes back to the current month.
Thanks
Here is one possible solution:
From eventClick callback, when you redirect the user to the other page. Also send current day, month and year of the calendar in the URL.
On that page get the values from URL and store them in session variables.
This is how you can get current date of the fullCalendar:
var calCurrDate = $('#calendar').fullCalendar('getView').start;
var date = calCurrDate.getDate();
var month = calCurrDate.getMonth();
var year = calCurrDate.getFullYear();
Now on calendar page check if those session variables are defined. If they are defined, add the following properties to fullCalendar
<cfif isDefined('SESSION.d')>
<cfoutput>
date: #SESSION.d#,
month: #SESSION.m#,
year: #SESSION.y#,
</cfoutput>
</cfif>
For server side language I've used Coldfusion (as I know only this). You can easily understand the logic and translate it to your desired language.
Note: At the end of the calendar page you must destroy the session variables. Otherwise every time when you refresh the page you'll be taken to the same day, month and year.
I hope this helps. Thanks