I want to display to users the time in different cities/timezones like this:
London 2012-02-01 11:30:00 GMT (0)
New York 2012-02-01 06:30:00 GMT (-6)
Stockholm 2012-02-01 12:30:00 GMT (+1)
I need it to be in ssjs and generic so that it does not matter which time zone the server is in.
I have been playing around with the following code lines but can not get it to work
var dt:NotesDateTime = session.createDateTime("Today");
dt.setNow()
//dt.convertToZone(-6,true)
//return dt.getGMTTime()
//return dt.getZoneTime()
GMT is ok, but users timezone is ok as well like GMT,UTC etc..
In this case I would stay away from the NotesDateTime object and use the Java Date object instead. You could do something like:
var d:java.util.Date = new java.util.Date();
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss z");
print(dateFormat.format(d));
dateFormat.setTimeZone(TimeZone.getTimeZone("Europe/London"));
print(dateFormat.format(d));
dateFormat.setTimeZone(TimeZone.getTimeZone("America/New_York"));
print(dateFormat.format(d));
Remember that changing a timezone for a Java Date doesn't change the date itself, it just changes how it is displayed.
Related
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 have a datepicker on my page, when I select any date it produced a result something like
Sun Sep 07 2014 00:00:00 GMT+0500 (Pakistan Standard Time)
And I need to format it: YYYY-MM-DDTHH:mm:ss Z
So, for this I use moment syntax
var date='Sun Sep 07 2014 00:00:00 GMT+0500 (Pakistan Standard Time)';
moment(date).format('YYYY-MM-DDTHH:mm:ss Z');
which produces an output
2014-09-07T00:00:00 +05:00
That's good, but my api expect standard timezone offset 'Z' instead of parsing into local current time zone (i.e +5:00) in my case.
So, I want to produce this
2014-09-07T00:00:00Z
How is it possible?
Use moment.utc() to display time in UTC time instead of local time:
var dateValue = moment(date).utc().format('YYYY-MM-DDTHH:mm:ss') + 'Z';
or moment().toISOString() to display a string in ISO format (format: YYYY-MM-DDTHH:mm:ss.sssZ, the timezone is always UTC):
var dateValue = moment(date).toISOString();
JSFiddle
Rather than using a hard-coded format string and then concatenating the 'Z' after it, it would be better to just use the toJSON() function which has been around since moment js v2.0. Like so:
moment('Sun Sep 07 2014 00:00:00 GMT+0500 (Pakistan Standard Time)').toJSON();
Here's the complete JSFiddle.
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>
Why does the ToUniversalTime function have no effect here;
DateTime dt = new DateTime(2009,3,24,1,0,0,DateTimeKind.Local);
dt = dt.ToUniversalTime(); // convert BST to UTC ?
dt.ToString();
"24/03/2009 01:00:00" ... wrong?
Is the same as..
DateTime dt = new DateTime(2009,3,24,1,0,0,DateTimeKind.Utc);
dt = dt.ToUniversalTime(); // nothing to do, already utc
dt.ToString();
"24/03/2009 01:00:00" ... correct.
I expected there to be an adjustment to the ToString() value of the first example, where by the DateTime specified as Local would result in a corresponding TimeZone calculation upon the call to ToUniversalTime() and the time in the UK should have resulted in
"24/03/2009 00:00:00" as UTC.
However it appears like the specifying of the DateTimeKind in this way renders ToUniversalTime or ToLocalTime unable to make any calculation.
Are you in the UK by any chance? Although we are now in daylight saving time, the date you specify in your code is before this switched over, so local and UTC time in the UK are the same. If you specify April as your month, then you will see a one hour difference.
Cheers David M.
Not had my breakfast. Indeed, when I repeat the test with dates that elapse the BST summer-time threshold, the behaviour is of course correct.
DateTime dt = new DateTime(2009,4,24,1,0,0,DateTimeKind.Local);
dt = dt.ToUniversalTime(); // convert BST to UTC ?
dt.ToString(); // "24/04/2009 00:00:00" ... correct
And to confirm, the ToString() method appears to output based on the Kind property.