When date was 2018-03-21 19:40, i tried following code
var date = new Date();
console.log(date);
Output :
2018-03-21T16:40:53.755Z
Server is missing for 3 hours as you see. I fixed it by adding 3 hours but I think it's not a good way. How can i fix this problem with better way ?
I don't think the date is incorrect, if you look closely at the format it is being printed, it has a Z at the end, which means:
A suffix which, when applied to a time, denotes a UTC offset of 00:00;
often spoken "Zulu" from the ICAO phonetic alphabet representation of
the letter "Z".
I guess you are in a place separated by 3 hours from UTC.
Node.js uses this format to print Date objects by default, but you can print your local time using toLocaleString():
console.log(date.toLocaleString());
Your server is most likely in another time zone.
Related
Inside my Docker-Container, which has the timezone Etc/UTC, I need to convert a Date-String which represents a Date in Europe/Berlin-timezone into a UTC timestamp.
So lets say the Europe/Berlin-Date is 2022-04-20T00:00:00.
Now the UTC-Timestamp should be equivalent to 2022-04-19T22:00:00.
But when I do
console.log(new Date("2022-04-20").getTime())
I get 1650412800000 which is equivalent to 2022-04-20T02:00:00 in Europe/Berlin-timezone.
How would I do this?
Edit:
I tried various libs, but still cant get that managed
const { DateTime } = require("luxon")
var f = DateTime.fromISO("2022-04-20").setZone('Europe/Berlin').toUTC()
console.log(f)
also the equivalent stamp in f is 2022-04-20T02:00:00 :/
I need to convert a Date-String which represents a Date in Europe/Berlin-timezone into a UTC timestamp.
Fundamentally, a date-only value cannot be converted into a timestamp, unless you arbitrarily associate a time with that date. It sounds like you meant to use midnight local time (00:00+02:00) but instead you are seeing midnight UTC (00:00Z).
This is due to how you are constructing the Date object. You specify new Date("2022-04-20"), which according to the ECMASCript spec will be treated as midnight UTC. The spec says:
... When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.
Yes, this is inconsistent with ISO 8601, and that has been discussed ad nauseum.
To solve this problem, append T00:00 to your input string, so that you are specifically asking for local time. In other words, new Date("2022-04-20T00:00").
That said, if you need it to not be "local time" but exactly Europe/Berlin, then yes - you'll need to use a library. In luxon, it's like this:
DateTime.fromISO('2022-04-20T00:00', {zone: 'Europe/Berlin'}).toUTC()
When I invoke the following code
moment('2020-01-01T00:00:00Z').endOf('month').utc().format()
I get the result
'2020-01-01T07:59:59Z'
when I would have expected to see
'2020-01-31T23:59:59Z'
Is this a bug or am I not using the API correctly?
I think the problem is you used endOf before you convert the Date in UTC.
You pass this Date : 2020-01-01T00:00:00Z but the browser understand it with your timezone so the "real date" is 2019-12-31T15:00:00Z.
So you must convert it to UTC first and then proceed your change/call/etc.
So, I tried that and it worked ! Tell me if the problem persist.
moment('2020-01-01T00:00:00Z').utc().endOf('month').format()
I'm trying to work with a curl request and the following string:
?created_from={FROM_TIMESTAMP}&created_to={TO_TIMESTAMP}
I've been working with the documentation quite a bit, so I know that brackets are not needed. Unfortunately, the only information I have is to us "Gregorian Timestamp" which I haven't found a lot of documentation on.
I have tried a number of different combinations. Using timestamps for 10-01-2018 to 10-02-18. Here's what I've tried:
?created_from=2019-02-01T00:00:00&created_to=2019-02-02T00:00:00)
This just returns logs from the past 30 days, not the specified date range.
Then I tried:
?created_from=1538352000&created_to=1538438400
This returns the following error message: "message":"created_to 63718254228 is more than 2682000 seconds from created_from 1538352000","cause":63718254228 which doesn't make sense to me because the created_from is 1538352000 not 63718254228.
I have also tried a bunch of other syntax and combinations of formats like the following:
?created_from=2018-10-29T00:00:00Z&created_to=2018-11-01T00:00:00Z
And many other tries. Does anyone know how to properly write a Gregorian timestamp in a curl variable request? I've searched everywhere.
Gregorian timestamps have an epoch date of 0-01-01 00:00:00 as opposed to the standard UNIX epoch of 1970-01-01 00:00:00, which as a Gregorian timestamp is 62167219200.
So, you can simply add that to a UNIX timestamp to get the Gregorian value.
For example, consider the datetime 02/24/2019 # 10:17pm (UTC), its UNIX timestamp is 1551046620. To obtain its Gregorian counterpart:
1551046620 + 62167219200 = 63718265820
So right now I'm trying to do the following:
grep "string" logfile.txt
which is going fine, but there's a lot of "string" in logfile.txt; I really only want to see the last hour's worth. In pseudo-code I want to do...
grep "string" logfile.txt OnlyShowThoseInTheLastHour
Is there any way to easily accomplish this in bash? In the logfile the lines look like this:
13:27:50 string morestuff morestuff morestuff
edit: sorry I forgot to mention it, but seeing logs from similar hours on past days is not an issue as these logs are refreshed/archived daily.
This should do it:
awk 'BEGIN { tm = strftime("%H:%M:%S", systime()-3600) } /string/ && $1 >= tm' logfile.txt
Replace string by the pattern you're interested in.
It works by first building a string holding time information from 1 hour ago in HH:MM:SS format, and then selecting those lines that only match string and have the first field (timestamp) lexicographically greater than or equal to the timestamp string just built.
Note that it has its limitations, for example, if you do this at 00:30, log entries from 23:30 through 23:59 will not match. In general, running this command anytime between 00:00 and 00:59 will possibly omit log entries from 23:00 through 23:59. However, this shouldn't be an issue for you, since you mentioned (in the comments) that logs archive and start fresh every midnight.
Also, leap seconds are not dealt with, but this is probably not a problem unless you need 100% precise results. And again - since logs start afresh at midnight, in your specific case this is not a problem at all.
I got the time values from the SBT SDK as a string in this format
"2013-07-17T14:44:25.177Z"
I get a Java Date object with this code
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
Date date = dateFormat.parse("2013-07-17T14:44:25.177Z");
But the last part of the string ".177Z" should be a time zone value !?!?!
Do any body know how parse the time zone or the complete date with the time zone in Java?
Thx
Andreas
But the last part of the string ".177Z" should be a time zone value !?!?!
No, I think the .177 is the milliseconds part, and Z is a UTC-offset of 0. (It's not really a time zone, but that's a different matter.)
I suspect you want:
SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSX");
(Where X is an ISO-8601 time zone specifier, including Z for UTC.)
Note that X was only introduced in Java 7 - if you're using Java 6 or earlier, you may need to do a bit more work.
You might want to use
javax.xml.bind.DatatypeConverter.parseTime(String)
since the dates found in the atom returned by the IBM Connections API conform to the definition from http://www.w3.org/TR/xmlschema-2/, which can be parsed into a Java Calendar Object by said method. This also accounts for the time zone specifier.