I'm trying to convert java datetime instant to hh:mm format using moment js
moment("2020-03-21T17:34:00Z").utcOffset(-0500).format("hh:mm")
it should give me 12:34, but somehow it is giving "12:14" which is the wrong time.
The moment js .utcOffset() method takes the offset in minutes.
so if you want to get 12:34 you need to use -300 instead of -0500
moment("2020-03-21T17:34:00Z").utcOffset(-300).format("hh:mm")
A few things:
The utcOffset function behaves differently whether you pass a string or a number. As a number, it's expected to be in terms of minutes. Since you have hours and minutes in your offset, you should pass it as a string: .utcOffset("-0500")
Format strings are case sensitive. You should use HH:mm (24-hour time), or hh:mm a (12-hour time). Since you used hh:mm without an a, anything after 12 pm will be misrepresented.
You are supplying a fixed offset. If that is your intent, then ok. But do recognize that there is a difference between an offset and a time zone. (See "Time Zone != Offset" in the timezone tag wiki.) For example, if you wanted to convert to US Eastern Time, you should use .tz('America/New_York) instead of .utcOffset("-0500"). (US Eastern time is at -4 for the date given, not -5.) You would need the moment-timezone addon to make this work.
Lastly, recognize that Moment is in maintenance mode. The moment team generally recommends Luxon for new development.
I'm using Moment.js and have been all over the docs trying to find the best way, if any, to instantiate a moment object from a local date string and an offset, when I need that object to be in UTC and reflect said offset in its hours. For example:
if I have that somewhere it's January 1st, 2019 midnight, and that somewhere's offset is -300, that would be 2019:01:01T00:00:00.000-05:00, right?, meaning it's 5 hours before UTC, so I need to be able to represent that in UTC like
moment.utc("2019-01-01T05:00:00.000+00:00")
What functions/transformations should I use for this purpose?
Thanks
I hope you are after this
moment.utc("2019-01-01 00:00:00").utcOffset(-300).format('YYYYMMDD HHmmss ZZ')
Note that the offset should be a number and not a string.
How does timezones works in javascript?
I'm trying to use moment.js but have some strange results.
In my zone moment().format() returns 2014-08-05T18:56:08+02:00.
But this one moment(0).format() returns 1970-01-01T01:00:00+01:00.
Why do the timezones differ?
You see the timezone differences due to the Daylight Saving Time (or Summer Time).
On moment=0 you timezone was not in DST so the offset by that time was +1 (I believe this is the normal offset in your region).
Right now, in the current moment you use moment(), your region is in DST so your current offset is +2. That's why you see the different offsets.
I've never used Javascript, but using google I found this link.
It looks like passing 0 as an argument constructs a time with a 0 millisecond offset from the start of Unix Time.
If we go 0 milliseconds from the start of unix time, we end up at the start of unix time. Which is Thursday, 1 January 1970.
I have a database (in CSV) with unix timestamps. I try to convert them in LibreOffice Calc into a human readable date. Everything is ok... except a one-day-lag.
For example, my timestamp is -518144400 (in E2 cell).
My function is : =E2/86400+DATEVAL("1/1/1970").
I obtain 19572,9583333333 which correspond to 1953-07-31.
This on-line calculator confirm the result.
What is the problem ? Just that the right answer is 1953-08-01.
First, I thought the timestamps contained a mistake. But, in this PHP calendar, if I paste -518144400 as parameter in the URL, it works. The on-line calendar associate this timestamp to (what I think is) the right answer.
I don't understand what happens. What I missed ?
One solution could be adding +1 in my function to correct. But I'm not satisfied, I'd like to understand...
It depends on conversion time zone, I mean that -518144400 (Timestamp) is equal to 1953-07-31 in GMT
While it will be 1953-08-01 in all other Time Zone where Time Relative to GTM is +1 or more.
How to represent the start and end times for one day?
Using October 23, 2008 as an example, is it start 2008-10-23 12:00:00 AM and end 2008-10-23 11:59:59 PM?
I would like to cite a site, http://www.cl.cam.ac.uk/~mgk25/iso-time.html
The international standard notation for the time of day is
hh:mm:ss
where hh is the number of complete hours that have passed since midnight (00-24), mm is the number of complete minutes that have passed since the start of the hour (00-59), and ss is the number of complete seconds since the start of the minute (00-60). If the hour value is 24, then the minute and second values must be zero.
Note: The value 60 for ss might sometimes be needed during an inserted leap second in an atomic time scale like Coordinated Universal Time (UTC). A single leap second 23:59:60 is inserted into the UTC time scale every few years as announced by the International Earth Rotation Service in Paris, to keep UTC from wandering away more than 0.9 s from the less constant astronomical time scale UT1, which is defined by the actual rotation of the earth. In practice you are not very likely to see a clock showing 23:59:60. Most synchronized clocks resynchronize again to UTC some time after a leap second has happened, or they temporarily slow down near the time of a leap seconds, to avoid any disruption that an out-of-range timestamp might otherwise cause.
An example time is
23:59:59
which represents the time one second before midnight.
As with the date notation, the separating colons can also be omitted as in
235959
and the precision can be reduced by omitting the seconds or both the seconds and minutes as in
23:59, 2359, or 23
It is also possible to add fractions of a second after a decimal dot or comma, for instance the time 5.8 ms before midnight can be written as
23:59:59.9942 or 235959.9942
As every day both starts and ends with midnight, the two notations 00:00 and 24:00 are available to distinguish the two midnights that can be associated with one date. This means that the following two notations refer to exactly the same point in time:
1995-02-04 24:00 = 1995-02-05 00:00
In case an unambiguous representation of time is required, 00:00 is usually the preferred notation for midnight and not 24:00. Digital clocks display 00:00 and not 24:00.
ISO 8601 does not specify, whether its notations specify a point in time or a time period. This means for example that ISO 8601 does not define whether 09:00 refers to the exact end of the ninth hour of the day or the period from 09:00 to 09:01 or anything else. The users of the standard must somehow agree on the exact interpretation of the time notation if this should be of any concern.
If a date and a time are displayed on the same line, then always write the date in front of the time. If a date and a time value are stored together in a single data field, then ISO 8601 suggests that they should be separated by a latin capital letter T, as in 19951231T235959.
A remark for readers from the U.S.:
The 24h time notation specified here has already been the de-facto standard all over the world in written language for decades. The only exception are a few English speaking countries, where still notations with hours between 1 and 12 and additions like “a.m.” and “p.m.” are in wide use. The common 24h international standard notation is widely used now even in England (e.g. at airports, cinemas, bus/train timetables, etc.). Most other languages do not even have abbreviations like “a.m.” and “p.m.” and the 12h notation is certainly hardly ever used on Continental Europe to write or display a time. Even in the U.S., the military and computer programmers have been using the 24h notation for a long time.
The old English 12h notation has many disadvantages like:
It is longer than the normal 24h notation.
It takes somewhat more time for humans to compare two times in 12h notation.
It is not clear, how 00:00, 12:00 and 24:00 are represented. Even encyclopedias and style manuals contain contradicting descriptions and a common quick fix seems to be to avoid “12:00 a.m./p.m.” altogether and write “noon”, “midnight”, or “12:01 a.m./p.m.” instead, although the word “midnight” still does not distinguish between 00:00 and 24:00 (midnight at the start or end of a given day).
It makes people often believe that the next day starts at the overflow from “12:59 a.m.” to “1:00 a.m.”, which is a common problem not only when people try to program the timer of VCRs shortly after midnight.
It is not easily comparable with a string compare operation.
It is not immediately clear for the unaware, whether the time between “12:00 a.m./p.m.” and “1:00 a.m./p.m.” starts at 00:00 or at 12:00, i.e. the English 12h notation is more difficult to understand.
Please consider the 12h time to be a relic from the dark ages when Roman numerals were used, the number zero had not yet been invented and analog clocks were the only known form of displaying a time. Please avoid using it today, especially in technical applications! Even in the U.S., the widely respected Chicago Manual of Style now recommends using the international standard time notation in publications.
Surely, if you just want to represent 1 day, you don't need to include the time at all - especially as this raises such a level of discussion about when a day starts or ends. In my experience, date handling is usually complicated enough, without introducing any extra complexity.
Today is Oct 20th 2008 - no more information is necessary.
Or am I missing something?
Oct. 23 starts at 2008-10-23 12AM and finishes at 2008-10-24 12AM—a day ends at the exact same point the next one begins. The very last second begins at 11:59:59 PM but you still have a whole second before the day is over.
Your notation is strange. I'd suggest the standard way of specifying a full day range is:
2008-10-23 00:00:00 and finish 2008-10-23 23:59:59
The definition of the day you mention in the question is any time that is >= 2008-10-23 00:00:00 and < 2008-10-24 00:00:00 .
If you were to use mathematical interval notation, you would write it as
[2008-10-23 00:00:00 , 2008-10-24 00:00:00)
The [ means inclusion, and ) means up to but not including.
In this way you make it easier for users and for yourself.
It depends what you mean by a day. Date handling is, sadly, always more complex than it looks.
To convert your example into 24h ISO date format, you'd say:
2008-10-23 00:00:00 - 2008-10-23 23:59:59
However depending on whether you interpret a range as inclusive or exclusive that could omit the last second of the day*. Programmers normally prefer to keep the upper bound exclusive, so you'd go for:
2008-10-23 00:00:00 - 2008-10-24 00:00:00
Or, as a slightly nicer way of stating the same, if supported (or for human readability):
2008-10-23 00:00:00 - 2008-10-23 24:00:00
*: actually possibly more than one. If the span represents a day in the UTC timezone (or another timezone aligned to it, which is quite likely), there can occasionally be an extra 'leap second' at the end of the day, 23:59:60, in a pointless attempt to keep UTC in line with sidereal time. The next leap second is planned for the end of this year. However, many systems ignore leap seconds because they're silly and annoying.
If you want to represent a 'calendar day' independently of timezones your best bet is the Julian day number. Today is 2454760.