if (serverinfo.now >= vacation.start && serverinfo.now <=
vacation.end) {
vacationIsActive = true;
}
In perl I would use 'ge' and 'le', and of course in C I'd use strcmp -
but I believe javascript uses the same operator for string comparison.
Keeping time and date accurate to within microseconds across a
distributed system is hard. Keeping it accurate to within a minute is
not difficult at all.
If this information has to be more accurate than a minute, you're
deluding yourself that it will be accurate on the client when it's
displayed.
The only time this would make sense is if the server actually made an
internal changed based on the start and end of the vacation time, by
setting an internal flag, and hence changing a modseq (aka: generating a
new state token for the vacation/filter rules data type).
But if the model is that the server stores vacation information as
a message and a date range in which that message is accurate, then
the protocol should say those facts - not computed values at a
point in time.
On Mon, Jun 27, 2016, at 18:22, D David wrote:
> Hey guys,
>
> So you really think we should recode the time-checking logic on all
> clients? Isn't that simpler to implement only at the server-level?
>
> Regards,
> David
>
>
> Le lundi 27 juin 2016 03:22:51 UTC+2, Neil Jenkins a écrit :
>> On Fri, 24 Jun 2016, at 08:44 PM, Bron Gondwana wrote:
>>> I'm generally adverse to sending calculated values like this through
>>> the API.
>>
>> Yes, I agree. This doesn't fit with the JMAP model, which as far as
>> possible tries to avoid sending calculated values due to the
>> difficulty in keeping them in sync.
>>
>>> I would be happy with an API call to get the server's current
>>> time value
>>
>> I think this is a better approach if this functionality is necessary
>> (I'm not entirely convinced it is, given that most devices these days
>> sync their clocks via the internet, so it's rare to be skewed more
>> than a second out).
>>
>> Neil.
>
> --
> You received this message because you are subscribed to the Google
> Groups "JMAP" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/jmap-discuss/83408ce5-cf57-45ee-a2b1-9527acc918c3%40googlegroups.com[1].
> For more options, visit https://groups.google.com/d/optout.
--
Bron Gondwana
[email protected]
Links:
1.
https://groups.google.com/d/msgid/jmap-discuss/83408ce5-cf57-45ee-a2b1-9527acc918c3%40googlegroups.com?utm_medium=email&utm_source=footer
--
You received this message because you are subscribed to the Google Groups
"JMAP" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jmap-discuss/1467016255.2574268.649378761.03D31EA4%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.
