Summer dates in an input control which are before 1981 are recalculated (I think with daylight saving time).
e.g.
e.g. I enter 27.8.1960 - after a save I got 26.8.1960, (after the next save 25.8.1960 and so on)
but 27.8.2010 - after a save it stayed the same: 27.8.2010
"Winter dates": 27.4.1960 - after a save it stayed the same: 27.4.1960
looks like an ugly bug. how can I supress this "calculation"?
(date format is Europeen, I live in Germany. 27.8.1960 is August 27, 1960)
thanks for any help, Uwe
<xp:inputText value="#{Auftrag.MF_GebDatum}" id="mF_GebDatum1" style="width:255px">
<xp:this.converter>
<xp:convertDateTime type="date"></xp:convertDateTime>
</xp:this.converter>
</xp:inputText>
The problem you are fighting with is that Domino stores a datetime value with the daylight saving information which does not exists for the dates you are entering. The information for the timezone to use comes from the current user locale and / or the server.
Your date is stored in a field with the timezone it was entered (+2h GMT)
26.08.1960 00:00:00 CEDT
Domino interprets the stored value as it is, without adjusting it
var ndt:NotesDateTime = session.createDateTime("26.08.1960 00:00:00 CEDT");
ndt.getGMTTime()
returns the correct datetime value, adjusted by 2 hours for GMT
25.08.60 22:00:00 GMT
While converted back to Java, it is interpreted "correctly" that there was never a daylight saving time in 1960, that's why it will be adjusted only by 1 hour:
var ndt:NotesDateTime = session.createDateTime("26.08.1960 00:00:00 CEDT");
ndt.toJavaDate().toLocaleString()
will result in "25.08.1960 23:00:00" if you are in the CEDT timezone.
Currently the only idea I have for an easy workaround is to kill the Timezone information in the DateTime field. To do this you can use this SSJS script:
<xp:this.querySaveDocument>
<![CDATA[#{javascript:
var doc:NotesDocument = document1.getDocument( true );
var items:java.util.Vector = doc.getItems();
var item:NotesItem;
var ndt:NotesDateTime;
var dt:java.util.Date;
for( var i=0; i<items.size(); i++){
item = items.get(i);
if( item.getType() === 1024 ){
ndt = item.getValueDateTimeArray().get(0);
ndt = session.createDateTime( ndt.getDateOnly());
item.setDateTimeValue( ndt );
ndt.recycle();
}
item.recycle();
}
}]]>
</xp:this.querySaveDocument>
Related
So I have the following script:
import groovy.time.TimeCategory
def dueDate = context.expand( '${Test 4 - create user task#Response#$[\'_embedded\'][\'userTaskDtoList\'][0][\'dueDate\']}' )
def date = new Date(messageExchange.getTimestamp())
use(groovy.time.TimeCategory){
after24Hours = (date + 24.hours).format("yyyy-MM-dd'T'HH:mm:ss'Z'", TimeZone.getTimeZone('UTC')) }
assert dueDate == after24Hours
What I'm trying to do with this is take the date and time from a REST request (dueDate - which comes in UTC format and with a 24h delay) and create a new date and time from the timestamp of the moment when that request has been sent, which is registered from my system. I then convert that time to UTC to accommodate the format from dueDate and add 24h to it. At the end I verify that the date and time from dueDate and after24Hours is the same.
The output does return the same time but in certain cases if there is a delay between the time the request is being sent and the time is received then the assertion will fail. This depends on the server, usually there is a difference of like 1 millisecond but I'm thinking that if the server will be slower at some point this will definitely be bigger.
What could I do to allow some margin of error in the assertion, maybe like a few seconds or even a couple of minutes?
Ok, so I managed to do this:
import groovy.time.*
def dueDate = context.expand( '${Test 4 - create user task#Response#$[\'_embedded\'][\'userTaskDtoList\'][0][\'dueDate\']}' )
def date = new Date(messageExchange.getTimestamp())
use(groovy.time.TimeCategory){
after24Hours = (date + 24.hours).format("yyyy-MM-dd'T'HH:mm:ss'Z'", TimeZone.getTimeZone('UTC'))
def date1 = Date.parse("yyyy-MM-dd'T'HH:mm:ss'Z'", dueDate)
def date2 = Date.parse("yyyy-MM-dd'T'HH:mm:ss'Z'", after24Hours)
TimeDuration difference = TimeCategory.minus(date2, date1)
log.info date1
log.info date2
assert difference < 2.minutes
}
The script seems to work and it does return an error only if the time is longer than the one I've set in the assertion.
Unfortunately I have another issue now.
For some reason, my date output looks like this:
Fri Oct 01 16:24:10 EEST 2021: INFO: Sat Oct 02 13:24:10 EEST 2021
Which is not the correct format. That date should appear in the Zulu format, after all when I parsed the dates that was the format that I used.
Am I missing something?
What could I do to allow some margin of error in the assertion, maybe
like a few seconds or even a couple of minutes?
Instead of asserting that they are equal, you could assert that the difference between them is less than a threshold that you get to define.
If you use something like AssertJ, and I'd recommend you do, then you can do something like the following:
assertThat(dueDate).isCloseTo(after24Hours, within(1, ChronoUnit.MINUTE));
This will give a small margin to the comparison of the dates, and should fix your issue.
I'm confused.
I have a textbox that is populated with a date and time (string) such as '09/07/2021 10:30'.
I convert this string to a moment like so:
var suggestedDateObj = moment(suggestedDate, 'DD/MM/YYYY HH:mm');
I then want to check if this date and time is in between time slots in a fullcalendar.js event object. I do this like so:
var startDateObj = moment(value.start);
var endDateObj = moment(value.end);
if (suggestedDateObj.isBetween(startDateObj, endDateObj)) {}
However...it isn't working. And it's due to timezone offset (i think).
suggestedDateObj returns a value with a UTC offset of +0100 (British Summer Time)
However my calendar event objects return a date with a UTC offset of +0000. So when i check if '09/07/2021 10:30 +0100' is in between '09/07/2021 10:30 +0000' and '09/07/2021 11:30 +0000' it doesn't work!
I guess my question is really either:
How can I create my suggestedDateObj moment with a timezone offset of zero? OR
How can i tell fullcallendar events that the time it is displaying is actually BST (+0100)? At the moment I don't specify the 'Timezone' parameter.
Thanks.
UPDATE
Hmm....this might work....although it feels a bit clunky:
var tmoment1 = moment(suggestedDate, 'DD/MM/YYYY HH:mm');
//create default date with specific timezone offset of zero
var suggestedDateObj = moment().utcOffset(0);
//set the date and time
suggestedDateObj.set({
day: tmoment1.day(),
month: tmoment1.month(),
year: tmoment1.year(),
hour: tmoment1.hour(),
minute: tmoment1.minute(),
second: 0
});
You can generate suggestedDateObj in utc like that:
var suggestedDateObj = moment.utc(suggestedDate, 'DD/MM/YYYY HH:mm');`
For the .isBetween() I suggest you to use the square bracket like forth parameter, like documentation says.
if (suggestedDateObj.isBetween(startDateObj, endDateObj, undefined, '[]'))
The square brackets indicate that the check must include the dates of the limiter
I have a complicated problem with time converting;
I am coding by node.js and use moment, moment-jalaali and moment-timezone
I get a time from clinet in jalali format( example: 1396-03-03T23:00:00.00+04:30) to search and find some data before or after a time which is saved on UTC; My server has -04:00 zone;
var moment = require('moment');
var momentJalali = require('moment-jalaali');
var momentTZ = require('moment-timezone');
var jFormat = "jYYYY-jM-jD HH:mm:ss z";
var format = "YYYY-M-D HH:mm:ss z";
var toDate = momentJalali(req.body.toDate, jFormat).tz('UTC').format(format);
console.log("date: \n" + toDate "\n " + moment().format('Z') + "\n"); //output: date:
2017-5-25 03:00:00 UTC
-04:00
The response I expect is 2017-5-24 19:30:00 UTC; How could I reach that?
You do not need moment-timezone for this. Simply parse the input in UTC mode. Since you provided an offset, it will be taken into account automatically.
moment.utc("1396-03-03T23:00:00.00+04:30", "jYYYY-jMM-jDDTHH:mm:ss.SSZ")
.format("YYYY-MM-DD HH:mm:ss z")
//=> "2017-05-24 18:30:00 UTC"
Also note you had a few formatting tokens wrong - they are case-sensitive.
Additionally, I would seriously consider not using that particular input format if you have any control over it. By convention, it appears to be in ISO-8601 extended format, except that ISO-8601 is strictly bound to the proleptic Gregorian calendar. My understanding is that Jalaali dates are typically written as 1396/3/3 23:00:00, which would be jYYYY/jM/jD HH:mm:ss.
Also note that the value you asked for in your question is actually an hour off. your local time is 4.5 hours ahead of UTC so subtract: 23 - 4.5 = 18.5, thus 18:30 UTC, not 19:30 UTC.
I have a date like "Thu Sep 01 2016 00:00:00 GMT+0530 (IST)" which I need to send to server as ISO-8601 utc time. I tried like :
moment(mydate).toISOString()
moment.utc(mydate).toISOString()
moment(mydate).utcOffset("+00:00").toISOString()
but I am getting the result like
2016-08-31T18:30:00.000Z
which is 1day behind my intended time. So what can I do to make moment ignore my local timezone and see it as UTC?
Edit:
The expected output is
2016-09-01T18:30:00.000Z
And no, the initial input isn't a string rather a javascript "new Date()" value.
Reason this happens:
This happens because .toISOString() returns a timestamp in UTC, even if the moment in question is in local mode. This is done to provide consistency with the specification for native JavaScript Date .toISOString()
Solution:
Use the same function and pass true value to it. This will prevent UTC Conversion.
moment(date).toISOString(true)
const date = new Date("2020-12-17T03:24:00");
const dateISOStringUTC = moment(date).toISOString();
const dateISOString = moment(date).toISOString(true);
console.log("Converted to UTC:" + dateISOStringUTC)
console.log("Actual Date value:" + dateISOString)
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.29.1/moment.min.js"></script>
I take the same problem today and find the solution.
Here is the solution: moment(date,moment.ISO_8601)
var date = new Date();
console.log("Original Date");
console.log(date);
console.log("After Moment Format");
console.log(moment(date,moment.ISO_8601));
Test Execution:
Moment Documentation: MomentJs
I'm trying to process a form with a datetime-local field to create a calendar event in a public google calendar. But when I run the program, all my dates default to December 31st 1969 at 4pm. Anyone have any ideas?
My script (which takes "form" as a parameter):
var event = cal.createEvent(form.myTitle, new Date(form.startTime+".000Z"), new Date(form.endTime+".000Z"));
Logger.log(form.startTime+" and "+form.endTime);
I added ".000Z" as per this solution, but I ran into the same problem even without adding it: Why does my Date object in Google Apps Script return NaN
What startTime and endTime are logged as:
2016-03-15T17:30 and 2016-03-15T19:30
But this is in the execution transcript:
Calendar.createEvent([NEW EVENT, Wed Dec 31 16:00:00 PST 1969, Wed Dec 31 16:00:00 PST 1969])
There are lots of ways to set a date object in JavaScript, but to set the correct date for a Google Calendar, you must do it in a very specific way. You must get the calendar time zone. For many people, if the users of their script are all in the same time zone, then the code will work. The problem comes when you have users across different time zones, or the time zone of the script is different than the time zone of the calendar. The code must construct a valid date string first, and then use the date string to create the date object. You can create a date object without a date string, and that would be preferable in most cases, because people can mess up the code to create the date string, but in this situation, you have no other choice (That I know of). Why? It's because of the time zone offset setting. The time zone offset setting is included in the date string. That is the key piece of information, that makes sure your dates will get set correctly, including for daylight savings.
function setCalendarEvent(){
var startTime = "2016-03-15T17:30";
var endTime = "2016-03-15T19:30";
//Always get the time zone of the calendar. If you don't do that, users accross different times zones will write bad dates
var calTimeZone = CalendarApp.getDefaultCalendar().getTimeZone();
//Construct a valid date string from the data
var startYr = startTime.slice(0,4);
var endYr = endTime.slice(0,4);
var startMonth = startTime.slice(5,7);
var endMonth = endTime.slice(5,7);
var startDay = startTime.slice(8,10);
var endDay = endTime.slice(8,10);
var startHrAndMin = startTime.slice(11,17);
var endHrAndMin = endTime.slice(11,17);
var startDateString = startMonth + "/" + startDay + "/" + startYr + " " + startHrAndMin + ":00 ";
var timeZoneOffset = Utilities.formatDate(new Date(startDateString),calTimeZone, "Z");
var startDateAsDate = new Date(startDateString + " " + timeZoneOffset);
Logger.log('startDateAsDate: ' + startDateAsDate)
};