Momentjs seems to be returning isAfter inconsistently but more often returns false when it seems like it should be true:
moment('2018-09-26T11:09:68').isAfter('2018-09-26T07:09:00')
This returned false, however, the first date/time is after the second.
It might due to the seconds(68)
11:09:68
in the first time stamp
Related
This question already has answers here:
How to make a timezone aware datetime object
(15 answers)
Closed 6 years ago.
I've got a datetime which has no timezone information. I'm now getting the timezone info and would like to add the timezone into the existed datetime instance, how can I do?
d = datetime.datetime.now()
tz = pytz.timezone('Asia/Taipei')
How to add the timezone info tz into datetime a
Use tz.localize(d) to localize the instance. From the documentation:
The first is to use the localize() method provided by the pytz library. This is used to localize a naive datetime (datetime with no timezone information):
>>> loc_dt = eastern.localize(datetime(2002, 10, 27, 6, 0, 0))
>>> print(loc_dt.strftime(fmt))
2002-10-27 06:00:00 EST-0500
If you don't use tz.localize(), but use datetime.replace(), chances are that a historical offset is used instead; tz.localize() will pick the right offset in effect for the given date. The US Eastern timezone DST start and end dates have changed over time, for example.
When you try to localize a datetime value that is ambiguous because it straddles the transition period from summer to winter time or vice-versa, the timezone will be consulted to see if the resulting datetime object should have .dst() return True or False. You can override the default for the timezone with the is_dst keyword argument for .localize():
dt = tz.localize(naive, is_dst=True)
or even switch off the choice altogether by setting is_dst=None. In that case, or in the rare cases there is no default set for a timezone, an ambiguous datetime value would lead to a AmbiguousTimeError exception being raised. The is_dst flag is only consulted for datetime values that are ambiguous and is ignored otherwise.
To go back the other way, turn a timezone-aware object back to a naive object, use .replace(tzinfo=None):
naivedt = awaredt.replace(tzinfo=None)
If you know that your original datetime was "measured" in the time zone you are trying to add to it, you could (but probably shouldn't) use replace rather than localize.
# d = datetime.datetime.now()
# tz = pytz.timezone('Asia/Taipei')
d = d.replace(tzinfo=tz)
I can imagine 2 times when this might make sense (the second one happened to me):
Your server locale is set to the incorrect time zone and you are trying to correct a datetime instance by making it aware of this incorrect timezone (and presumably later localizing it to the "correct" time zone so the values of now() match up to other times you are comparing it to (your watch, perhaps)
You want to "tag" a time instance (NOT a datetime) with a time zone (tzinfo) attribute so that attribute can be used later to form a full datetime instance.
I'm using Joi package to validate a timestamp field but How can I set a max() value on it, I want the input timestamp to be less than current time stamp
var schema = Joi.object().keys({
t: Joi.date().timestamp('unix').max(moment().unix()),
})
but I get the error that:
child "t" fails because ["t" must be less than or equal to "Sun Jan 18
1970 07:35:17 GMT+0330 (IRST)"]
I'm sure that the moment().unix() returns the current timestamp, but here it is casted to string.
It seems that max() and min() functions can do the trick but they only work if the threshold is specified in milliseconds.
t: Joi.date().timestamp('unix')
.max(moment().unix() * 1000)
.min(moment().subtract('42', 'weeks').unix() * 1000),
It doesn't look like Joi.date().max() accepts unix timestamps properly despite being able to specify in your schema that a unix timestamp is expected for incoming values.
If you need to use the current date in your schema you can pass the string 'now' instead of using the date. Or just make sure you enter the current date in format that .max() expects. I tried this using milliseconds and it seems to work as expected. I think Joi is using the default Date constructor under the hood to construct dates to compare which expects milliseconds.
var schema = Joi.object().keys({
t: Joi.date().timestamp('unix').max(moment().unix() * 1000)
});
From the docs on date.max()
Notes: 'now' can be passed in lieu of date so as to always compare relatively to the current date, allowing to explicitly ensure a date is either in the past or in the future.
I've found a couple of existing StackoverFlow questions on this but nothing very definite.
I have a local datetime. I want this in UTC. my local datetime does not have a 'Z' at the end or any offset information.
I first tried:
moment(mylocaldatetime).toISOString() #works fine because this method always returns time in UTC
But for consistency with other code I didn't want to use to ISOString() so I did this:
moment(mylocaldatetime).utc().format()
This seems to work fine. If the browser running this code is in UTC + 1 I get a datetime one hour less than mylocaldatetime (with an offset string if I specify that in the format). I.e. it has treated mylocaldatetime as a local time, taken account of my current time zone, and given me my local time as UTC.
However. This appears to contradict the moment.js docs which are pretty clear that:
If you want to parse or display a moment in UTC, you can use moment.utc() instead of moment(). - Notice the 'parse'.
and
Moment normally interprets input times as local times (or UTC times if moment.utc() is used).
If these doc comments were true this line:
moment(mylocaldatetime).utc().format()
should treat mylocaldatetime as if it were utc and then output this datetime in utc - no difference. No conversion. But that is not what I get.
Maybe what this line moment(mylocaldatetime).utc().format() is saying is:
create a moment object in local mode with mylocaldatetime. Then put the moment object into utc mode. So now when we format for display we output as utc. IF this is the case I think the docs could be made clearer.
Does the below 2 syntaxes are same,
moment(1456261200367, 'H:mm:ss.SSS').utc().valueOf() //1456343786120
moment(1456261200367 +0000, 'H:mm:ss.SSS Z').valueOf() //1456325786120
but as you could see if both of them coverts the given value to UTC mode then why there is a difference in the output?
Also I would like to know how a.valueOf() and b.valueOf() are same, when a.format() and b.format() are different, because moment() (moment parses and displays in local time) is different from moment.utc() (displays a moment in UTC mode)
var a = moment();
var b = moment.utc();
a.format();
b.format();
a.valueOf();
b.valueOf();
In the first part, you're using it incorrectly. You've passed numeric input which would normally be interpreted as a unix timestamp, but then you've supplied a string-based format string so the number is converted to a string. The format string here is telling moment how the input is specified, but it doesn't match what you're actually parsing.
This doesn't error though, because by default moment's parser is in "forgiving" mode. You can read more about this in the docs.
The correct way to pass a timestamp into moment is with one of these:
moment(1456261200367)
moment(1456261200367).utc()
moment.utc(1456261200367)
The last two are equivalent, but the moment.utc(timestamp) form is prefered.
With any of those, all three will have the same .valueOf(), which is just the timestamp you started with. The difference is in the mode that the moment object is in. The first one is in local mode, reflecting the time zone of the computer where it's running, while the other two are in UTC mode.
This is evident when you format the output using the format function, as with other many other functions. I believe that answers your second question as well.
I have the following code that I don't believe is functioning properly and I cannot figure out why.
dim total as decimal? = If(first Is Nothing OrElse second Is Nothing, _
Nothing, _
Math.Abs(If(first, 0D)) - Math.Abs(If(second, 0D)))
If either first or second are nothing, then nothing needs to be placed in the total. However, if they both have values, they both need to be changed to positive values and first - second needs to be calculated. First and second are both nullable decimals (decimal?).
Expected results:
first = nothing
second = nothing
total = nothing
Actual results:
first = nothing
second = nothing
total = 0D
I cannot understand why the if statement is not jumping to the true segment and putting Nothing into the variable total
The If() operator is strongly-typed, but the compiler has to infer the type of the result based on the inputs.
In this case, it can't infer the type from the first option (Nothing), because Nothing by itself has no type, and unlike C#'s null, Nothing can reduce to a value type (this will be important in a moment). Therefore the compiler has to look at the second option: Math.Abs(If(first, 0D)) - Math.Abs(If(second, 0D)). The type of this expression evaluates out to a Decimal... not a Decimal?. Therefore, the resulting type of your entire If() expression is a Decimal, and not a Decimal?. That you assign the result to a Decimal? doesn't matter.
I cannot understand why the if statement is not jumping to the true segment and putting Nothing into the variable total
That is exactly what it's doing. However, as mentioned earlier, Nothing in VB.Net can be assigned to value types. Before the assignment can occur, Nothing is converted to a Decimal, because this is the result type of that If() expression. In case of a Decimal, assigning the value of Nothing results in the default Decimal value of 0D... hence your results.
I haven't tested this, but I think you could fix this to get your desired results by explicitly casting the False expression in your If() operator as a Decimal?/Nullable(Of Decimal). This will tell the compiler to infer Decimal? instead of Decimal for the type of the If() expression, and therefore returning Nothing from that expression will have desired output.
I have reverted to make a compiler extension that allows the absolute value function to be performed on a nullable decimal, returning the value if it is Nothing or non-negative, otherwise multiply by -1 and return. That way if it returns nothing the computation result is as expected.
dim total as decimal? = first.ToAbsoluteValue() - second.ToAbsoluteValue()
<System.Runtime.CompilerServices.Extension()>
Friend Function ToAbsoluteValue(value As Decimal?) As Decimal?
If value Is Nothing OrElse value >= 0 Then Return value
Return Math.Abs(If(value, 0D))
End Function
If anyone knows how to add this to the Math.Abs() overloads that would be a much cleaner option.