Like the title says, I have two moment values. From the first I need to grab the date (will be a future date) and from the second value I need to grab the time. I looked at this here about connecting two values, but didnt exaclty work
So the first moment() returns Thu Jun 28 2021 15:45:50 GMT-0400 of which i need the dayte
The second moment() returns Thu Jun 24 2021 16:42:50 GMT-0400 of which i need the time
What is best way to put the two moment values together ? so i would get Thu Jun 28 2021 16:42:50 GMT-0400
The way I did it is with moment().set()
like this moment(myDate).set('hour', moment(myTime).format('HH')).set('minute', moment(time).format('mm'));
Related
I am working with a data set where the Period is given as
2001.01,2001.02,2001.03......When I am trying to convert it using yearmon() it shows only Jan and Feb this two month.For
example for 2001.05 it shows Jan 2001. But it should be May 2001. I think I need to convert the Period in 2001-01 format
first before using yearmon(). Can anyone plz tell me how can I do it?
today there is November (DST). I set File date time with :
TFile.SetCreationTime(FilePath, ADateTime);
If I set date time to: '2021-11-11 02:27:00' read in Windows Explorer is as set.
If I set date time to: '2021-05-14 02:27:00' then date is OK but hour read in Windows Explorer is 03:27.
How to set hour to 02:27:00 independently of DST?
The documentation on TFile.SetCreationTime() isn't great. However, since also a method TFile.SetCreationTimeUtc() exists the former will most likely interpret the TDateTime as local time (the currently chosen timezone in an operating account's settings), while the latter will interpret it as system time (UTC = GMT = timezone 0000).
Long story short: keep yourself from trouble and operate on UTC times, which also doesn't know daylight saving. Examples:
Germany is in timezone +0100, with DST +0200 during summer (which means 1 or 2 hours ahead of UTC).
Most of Brazil is in timezone -0300, with DST -0200 during summer up to the recent past (which means 3 or 2 behind UTC).
I'm trying to understand a saved game file format.
The game is written with Unity.(not sure that it's related)
The file is a JSON file and the timestamp is:
"Timestamp": 637015624965194930,
This translates to Aug 16th 2019 at 14:28
another example is:
"Timestamp": 637014628610503310,
This translates to Aug 15th 2019 at 10:47
I figured that subtracting the 2 numbers will give me the difference and it kind of works.
It seems that the time is measured in 1/10000000 of a second.
Can anyone figure out how to convert this to EPOCH time?
This time is 1/10000000 of a second since Jan 1st 0001
It is the standard time format used by .NET
so you can subtract 621355968000000000 (Jan 1st 1970) and divide by 10000000 to get seconds since EPOCH.
I have a data set with dates in the following format.
date
2018-09-03 07:56:29 -0500
2018-03-29 14:03:52 -0600
I want to convert them to the following format without changing the time zone (I don't know if the time zone could be an issue in this case. The column doesn't specify the time zone. I live in Mexico. I would prefer to have dates according to Mexico time zone. The time zone of Mexico city is UTC-5h when DST start and UTC-6h when DST end.)
date
2018-09-03 07:56:29 AM
2018-03-29 14:03:52 PM
Any help will be highly appreciated!
The date format you show implies that the data is in Zulu time (or Greenwich Mean Time, or Universal Time). That means they are adjusted to the UTC time by subtracting the hours shown at the end.
If you simply ignore the adder, your times will be wrong, depending on where they were taken. For example, the first one has -0500, which is EST (Eastern US time), but the second line with -0600 is CST (Central US time). So they were measured in two different time zones, which are one hour apart. You cannot ignore that without introducing error.
The correct interpretation is to convert them to your target timezone (I am not sure which time zone Mexico is on - CST?).
Adding the AM or PM to it is superfluous, as the PM times are shown as 12:01 - 23:59, whereas the AM times will be 00:01 - 11:59. You can certainly add it, to make it easier to read for people who are not used to use a 24-h clock, but they don't contain new information.
Why 7/18/2013 11:33 is different in GMT timezone and in my local Time Zone (Asia/kolkata)?
As Unix time-stamp are the ticks being calculated since epoch time 1/1/1970 00:00:00 GMT so i know that there the epoch time had occurred at different interval in different timezone but still. the number of second elapsed should have been same
For example if I(+5:30 GMT) and My friend(+5:00 GMT) starts counting the ticks from 00:00 Hrs respectively so at 18:00 Hrs in both timezone number of ticks should be same. So why same thing is not true with the Unix time-stamp.
Need to Understand the concept fully.
For example if I(+5:30 GMT) and My friend(+5:00 GMT) starts counting the ticks from 00:00 Hrs respectively so at 18:00 Hrs in both timezone number of ticks should be same.
No, because both of you start counting from 00:00 UTC. That's the definition. So for you, that will mean the number of ticks since 18:30, and for your friend it will mean the number of ticks since 19:00.
The idea is that a single instant in time has the same timestamp value everywhere. So if I were calling you now (and ignoring phone delays) we could both agree that "now" is a Unix timestamp of 1374130418. You may have a different local time to me, but we can express "now" in a common format.
See the "core concepts" part of the Noda Time user guide for more discussion of local time vs "global" time.
When your system is configured correctly, the unix time stamp shows you the ticks since 1.1.1970 in Greenwich. So when you an your friend read the timestamp at 18:00 at your local time, you do it with 30 minutes delay and therefore have 1800 seconds difference.
If this isn't the case, one or both of the system clocks isn't set correctly to use GMT as base. Usually this kind of problem doesn't have negative impact as long as you're just working on one system or all systems are set incorrectly the same way.
The Unix time is given as seconds since the epoch: the number of seconds (not counting leap seconds) that have passed since 00:00:00 Coordinated Universal Time (UTC), or Thursday, January 1st, 1970,
The GNU date command has some very nice features that allow you to translate between different time formats. These are explained very nicely in man date so I will only give you some examples here:
### "Normal" format
$ date
Thu Jun 12 11:44:23 CEST 2014
### Unix time
$ date +%s
1402566271
To convert, you can give date a specific date using the -d flag. However, to get a Unix date, this needs to be a full date. You can't convert 3:00PM to Unix time since Unix time refers to an entire date (year,month,day,time). So, for example, to get the Unix date for the 12th of September 1987, you would do:
$ date -d "3 PM 12 September 1987" +%s
558450000
And to convert that back to a "normal" date:
$ date -d "#558450000"
Sat Sep 12 15:00:00 CEST 1987