I need to format two moment objects to display a time range to users, eg:
6:45PM-9:30PM
I know I can get this with
`${time1.format('h:mmA')}-${time2.format('h:mmA')}`
but I want to suppress minutes when either the start or end time is on the hour, eg:
6:45PM-10PM (instead of 6:45PM-10:00PM)
7PM-9:30PM (instead of 7:00PM-9:30PM)
7PM-10PM (instead of 7:00PM-10:00PM)
I can check to see if the minutes are 0 before and change my formatting string based on that, but that seems inelegant I'd like to do this only using .format if possible. Haven't found anything in the formatting docs about this.
.format does not provide that you want inbuilt. Rather you can use string replace function instead.
`${time1.format('h:mmA').replace(":00","")}-${time2.format('h:mmA').replace(":00","")}`
Do IF statements work using timestamps? I'm using a Google Sheet from a Google Form and would like to use the Timestamp as a matching identifier.
Code:
if (time == homeTime) {
s.getRange(7, 1).setValue("Yay!");
Logger.log shows both variables are indeed the same value (Tue Jun 26 08:47:52 GMT-04:00 2018).
It works if I choose a value other than the timestamp, such as an email address.
I cannot use < or > because I'm using this in a for loop. As a temporary fix, I changed the format of the column to Plain Text using #, but time - homeTime == 0 is the answer I needed!
I'm trying to figure out how to mark my answer correctly so I apologize if I mess it up.
I am making a project to select date and time for making appointment( img below). I am giving id to label as combination of date and time. for example id
"2015-08-24 10:00 am" is given to label showing time 10:00 am.
this is mandatory for me to give id like this to highlight all label falling under this service time slot.(in this case service time slot is of 170 min)
till now it is working fine. but can it cause some problem in future for me to give id like this???
sorry for my poor english....................
can it cause some problem in future for me to give id like this?
Maybe, it depends on how you use them. But it's invalid, id values cannot contain spaces.
Instead of using id, I'd suggest using a data-* attribute, such as data-value="2015-08-24 10:00 am".
If I were going to use that value in JavaScript, I'd also probably put that value in the standard JavaScript form (as of the most recent spec, this is a subset of ISO-8601; prior to that, the spec had an error in it which make it not quite a subset): 2015-08-24T10:00 (plus any timezone if relevant).
I'm a typically server side developer feeling a bit like a fish out of water trying to display time values on the front end. How can I get behavior like PHP's date() and strtotime() functions out of moment.js? I just want a unix timestamp to appear in H:i:s format, and vice versa.
So far I've tried the following, from existing example code and the documentation:
moment(timestamp).format(H:i:s);
moment().duration(timestamp).format(H:i:s);
moment.unix(timestamp).format(h:mm:ss);
moment(formatted,'H:i:s');
Not a SINGLE one of which has worked properly. This may get flagged as duplicate since there are plenty of moment.js questions out there, but I don't know whether it's been updates to the library itself or slightly different context, I have not found one existing solution that has worked for me.
Anybody have any suggestions for these two simple tasks?
EDIT:
I've distilled two different problems out of this. One is that functions the moment docs say should work are giving weird values:
moment(1437462000).format('h:mm:ss')
for instance, which should return 7:00:00 utc, returns 10:17:42. This can be fixed in this case by using moment.unix(1437462000).utc().format('h:mm:ss') instead, but this leads into the second problem - the .utc() function seems to get ignored when converting back from a date into a timestamp:
timestamp = moment(formatted,'DD/MM/YYYY H:m:s').utc().unix();
will still return a timezone corrected value (in my case this is incorrect by several hours since the formatted time in question has nothing to do with the client computer) regardless of whether the .utc() function is included or not.
A few things you should realize:
Unix timestamps should always in terms of UTC. They are never adjusted for time zone in numerical form. If they're adjusted for time zone, that's done during the interpretation of the number, not in its representation.
While traditionally a "Unix Timestamp" is in terms of seconds, many environments use milliseconds instead. PHP's date timestamps are based on seconds, while moment and JavaScript's Date object both use milliseconds by default. Using the moment.unix function will let you pass seconds, and is identical to just multiplying the timestamp by 1000.
Moment has two built-in modes, local and UTC. The default mode is local. It doesn't matter what input you provide, if you don't specify UTC, the moment is adjusted to local. To specify UTC, you use the utc function. There are two forms of the function:
moment.utc(input) // parsing form
moment(input).utc() // conversion form
Both forms take some input and result in a moment in UTC mode. The difference is in how the input is interpreted. In either case, if the input value is unambiguous, the result is the same. For strings, that means the input would contain either a Z (from ISO8601), or a UTC-based offset. All other forms are ambiguous. For example, if I pass "2015-11-08 01:23:45", I will get different results depending on whether I interpret that string as local time or as UTC.
For numbers, they are always interpreted as milliseconds in UTC. However, if you use moment(number) without then calling .utc() then the moment is left in local mode, so any output will display as local time.
When you call moment.unix(input), the input is a number of seconds, but the moment is left in local mode. So to display the UTC time, you would use moment.unix(input).utc().
If your pre-recorded timestamps from your other system are in numeric form, but have been adjusted away from UTC, then they are incorrect. You have bad data, and Moment can't help you unless you know specifically how they have deviated and you write code to counteract that.
Moment's formatters are case sensitive. M is months, m is minutes. H is hours on a 24-hour clock, h is hours on a 12-hour clock. Use two consecutive letters when you want to include zero-padding. Example, HH:mm:ss for 13:02:03 vs. h:m:s for 1:2:3.
Moment's X formatter does not care which mode the moment is in. It will always emit seconds in UTC. Likewise, the x formatter returns milliseconds in UTC, as does moment.valueOf().
Also, your last example:
moment.unix(1437462000).utc().format()
Returns "2015-07-21T07:00:00+00:00" - which I believe is the value you expected.
You also get the same original timestamp regardless of which of these you try:
moment.unix(1437462000).utc().format("X") // "1437462000"
moment.unix(1437462000).format("X") // "1437462000"
moment.unix(1437462000).utc().unix() // 1437462000
moment.unix(1437462000).unix() // 1437462000
For anyone who comes in and is still looking for direct PHP equivalents for date() and strtotime(), here are the ones I ended up using. Matching up to php basically means just completely ignoring any kind of local time information by making sure everything is in UTC. That task is a little different between the timestamp->date and date->timestamp cases, though, so you have to be careful.
date()
Converting a timestamp to formatted date without any client timezone correction
var formatted = moment.unix(timestamp).utc().format('h:mm:ss');
strtotime()
Converting a UTC formatted date back to a timestamp without correcting it to local time:
var new_timestamp = moment.utc(formatted_utc,'DD/MM/YYYY H:m:s').format('X')
//where 'DD/MM/YYYY H:m:s' is the formatted date's format, and
//'X' outputs a unix timestamp without milliseconds.
Notes:
Do not use moment() with parenthesis in the calls:
moment().utc(date,format) will return local time values, not your
input.
Moment.js does not like the use of 'i' for minutes in the formatting,
unlike php.
I've created an app that takes in HTML inputs and goes through JavaScript to create an event on a native calendar events. It takes the time from the <input type="datetime-local">, and it's putting in a different time because it's picking a different time zone. If I enter 1 o'clock PM as a time it will return 8 o'clock AM.
<input type="datetime-local" id="startDate" name="startDate">
And the JavaScript:
var startDate = new Date($("#startDate").val());
Any help would be awesome. I can post more code if needed.
The HTML5 datetime-local input type will give you a string value back, which contains the date and time in ISO8601 format, with minute precision, and without any time zone offset.
For example: 2014-07-12T01:00
The JavaScript date object is notoriously inconsistent when it comes to parsing dates from strings. In most implementations, when you provide a string like this, it erroneously assumes the value is in UTC. Therefore, the Date object you get back will be adjusted by the time zone offset from your local computer.
There are two approaches to work around the problem:
Option 1
Manipulate the string to a format that will likely be interpreted as local time by the Date object's parser. Specifically, replace the dashes (-) with forward slashes (/) and replace the T with a space.
var s = $("#startDate").val();
var startDate = new Date(s.replace(/-/g,'/').replace('T',' '));
Option 2
Use a library with more capable date parsing abilities. There are several available. One of the most popular is moment.js.
Moment.js has lots of options, but it just so happens that the default behavior is exactly what you need. So you can just pass the string to the moment constructor without any parameters.
var s = $("#startDate").val();
var startDate = moment(s).toDate();