alumniq / momentcfc Goto Github PK

invalid call of the function from, first Argument (compare) is of invalid type, can't cast Object type [DateTime] to a value of type [moment]

First of all, thanks for this cfc, I love moment.js and I am excited to see that functionality brought to cfml.

As it stands now, moment.cfc in the format() method will format for the current timezone of the server no matter what zone the moment has. (Easily seen by using a mask of 'long' or including the zone offset in the mask: 'zzzz').

Even if you are not interested in displaying the zone info in the formatted string, it could still be an issue, because of the times that are invalid due to the timezone (e.g. 2015-03-08 02:30AM in the America/New_York zone). If, for example, the server is not running on UTC but America/New_York, and maybe you don't care about this since the server ought to be on UTC :), then trying to convert 2015-03-07 09:30PM EST to UTC and outputting it will result in 2015-03-08 03:30AM, when it should be 2015-03-07 02:30AM.

<cfset date = new "/dailysandbox/cfc/lib/moment"("02/18/2016 12:10 PM")>
<cfdump var="#date.format("hh:mm tt")#" abort>

I get 12:02 PM and that is wrong.....

line 49, 'zone' needs to be 'this.zone'.

several querying functions make use of the .utc() mutator to do math/comparisons against utc for correctness, but this leaves the original object in an undesired state. Clone these moments before calling .utc() on them...

Per the moment.js docs
http://momentjs.com/docs/#/manipulating/start-of/

These are really useful mutators when working with a moment

There's an issue when converting times from local to UTC and vice versa. The issue is when you get the offset, you get the offset based upon the current time stamp.

For example, if you were to UTCtoTZ("2015-02-01 05:00:00", "America/New_York"), you should get midnight. However, if you run the code today, the offset is going to be -4, instead of -5. This is because you're getting the current timestamp for the offset.

To resolve the problem, you need to feed the offset in the date/time of what you're converting.

Here's a sample of the logic I've used in the past when converting local to UTC:

// get the milliseconds from epoch of the supplied date/time
var ms = timezone.getOffset( javacast("long", dateDiff("s", createDateTime(1970, 1, 1, 0, 0, 0), arguments.time)) )*1000;

This would get the seconds from Epoch of the time that you supplied, so you're getting the correct offset based on the time you supplied.

is: iso8061
should be: iso8601

x = moment( '2008-11-27 06:06', 'America/Los_Angeles' );
x.tz( 'Asia/Hong_Kong' );
x.epoch();
//expect: 1227794760000 (same epoch as when it's in LA)
//actual: 1227852360000

This relates to #6, because the custom utc offset we're generating at initialization isn't being updated when the time zone changes.

Maybe its just me but the current return from the fromNow() method is somewhat confusing. If its less than 7 days will return Last Someday. This to me, can be a bit confusing say you had passed yesterdays date to the component it would return Last Wednesday which can be a bit confusing for some. Even though i think thats technically correct, some would think Last Wednesday as in 1 week ago Wednesday and not Yesterday. Would it be better to further check diff and return either yesterday or # days ago? And modify the weeks to return Last Someday or as it already is # weeks ago?

e.g. moment.hour(13) sets the hour of the moment to 1pm, but moment.hour() returns the current hour value.

e.g.:

x = new moment();
x.format( 'mysql' );

• mysql: yyyy-mm-dd hh:nn:ss
• mssql: yyyy-mm-ddThh:nn:ssZ

I just noticed this piece of code

public function epoch() hint="returns the number of milliseconds since 1/1/1970 (local). Call .utc() first to get utc epoch" {
  /*
        It seems that we can't get CF to give us an actual UTC datetime object without using DateConvert(), which we
        can not rely on, because it depends on the system time being the local time converting from/to. Instead, we've
        devised a system of detecting the target time zone's offset and using it here (the only place it seems necessary)
        to return the expected epoch values.
*/
    return this.clone().getDateTime().getTime() - this.utc_conversion_offset;
    var adjustment = (this.utc_conversion_offset > 0) ? -1 : 1;
    return this.clone().getDateTime().getTime();
    return this.clone().getDateTime().getTime() - (this.utc_conversion_offset * adjustment);
}

Only the first return will get executed! Why the other code?

Template: https://github.com/marcins/cfml-ci

• System time UTC
• x = new moment( '2008-11-27', 'America/New_York' );
• x.epoch()
  • expect: 1227762000000 (midnight (am) 11/27 local)
  • but get: 1227744000000 (7pm 11/26 local)
  • actual is 5 hours off, which matches the DST offset - but I'm not sure why it's off, yet.