CurrDate() returns wrong date

CurrDate() returns wrong date

  

I am Using CurrDate() to slected records for the current day, and it works most of the daye, but after about 7pm, starts to select the records for the next day. It happens in all the devices and even in the browser emulator. In the bottom right of the picture you can see that the date is 5/16/2017, but the app is picking records for the 17th. Any ideas?

Here is my get filter.

Are you using personal environment or enterprise environment?

Check your server timezone.

It looks indeed a timezone conversion, but only the DateTime should be affected by them. Not the "Date" type.


Can you share a module that replicates the wrong behavior? It would help a lot understanding what is happening if we knew what are the types involved, how/where the dates are being set in the database and what operations happening on the client or server side.


Regards,

João Rosado

Harlin Setiadarma wrote:

Are you using personal environment or enterprise environment?

Check your server timezone.

Harlin, thanks for replying. I am using  personal environment


Joao,

Thanks for replaying.

When you say the "the module" do you mean my entire app or just that screen?


Gonzalo

João Rosado wrote:

It looks indeed a timezone conversion, but only the DateTime should be affected by them. Not the "Date" type.


Can you share a module that replicates the wrong behavior? It would help a lot understanding what is happening if we knew what are the types involved, how/where the dates are being set in the database and what operations happening on the client or server side.


Regards,

João Rosado



This is a constant problem with the current date/time implementation when using the Personal Environment because you do not have control over the server time zone setting.  The server uses the date/time for Portugal which happens to be UTC or GMT.  You are very likely in the Eastern US which is UTC-5, which is why you see the date change at 7 pm.  Even though you don't use time in your query, the time value is used to determine the correct date internally so you have the same issue whether you use CurrDate() or CurrDateTime().  The best option is whenever you store a date or date/time store it as UTC.  For example since you know you are -5 hours, add five hours to determine the date and store that.  When displaying those dates and times you have to subtract out the same five hours.  Storing it as UTC will also allow you to handle multiple time zones if needed by adding the correct offset.  There are some timezone components in the Forge that can help with this.

Hope this helps,
Curt


Thanks, this makes sense. Could I extract the date component from the datetime() function and use that instead?



Curt Raddatz wrote:

This is a constant problem with the current date/time implementation when using the Personal Environment because you do not have control over the server time zone setting.  The server uses the date/time for Portugal which happens to be UTC or GMT.  You are very likely in the Eastern US which is UTC-5, which is why you see the date change at 7 pm.  Even though you don't use time in your query, the time value is used to determine the correct date internally so you have the same issue whether you use CurrDate() or CurrDateTime().  The best option is whenever you store a date or date/time store it as UTC.  For example since you know you are -5 hours, add five hours to determine the date and store that.  When displaying those dates and times you have to subtract out the same five hours.  Storing it as UTC will also allow you to handle multiple time zones if needed by adding the correct offset.  There are some timezone components in the Forge that can help with this.

Hope this helps,
Curt




Hi,


By module I was saying a application that can reproduce the problem. It may be your application or a new application just for a demo just the minimum required parts that simulate what is happening.


What Curt says happens with the "DateTime" types. But from the screenshots you seem to be using "Date" that should not have that behavior. (Also the Personals are not in the Portugal timezone, they are explicitly set to UTC)


Regards,
João Rosado

Thanks Joao,


I am not sure about what to do. I thought the CurrDate() function returned the device's date, not the server. If I have to subtract time zones from UTC to calculate the right date across the US, how do I know where the user is so I can determine hoe many hours to subtract?

Gonzalo

Just to clarify, CurrDate() and CurrDateTime() have the same behavior, as I described earlier.  For example, assume it is May 17 at 7:05 pm eastern US time (UTC-5).  If I interrogate CurrDate() it will show May 18 because the server is set to UTC.  This is because the server changes the date whenever midnight passes and midnight on the server occurred five minutes ago.  Therefore CurrDate() is just as dependent on time as CurrDateTime().

Curt


Thanks Curt,


So, why should my permission look like in order to ensure I correct for location of the device? Right now it looks like this:

Assuming you have existing data in the TaskDate field you would need to know whether the dates in that field were set by CurrDate() or by some other means.  If this is consistent, then you should be able to use the built-in date time functions to get the selection you want.  If the data is a mix of values it will be impossible to do this with 100% accuracy.  (I don't have access to my environment at this time so I can't show exactly what I would do.)

Curt


The date for each record is in a field coming from a remote Server SQL database, and the data type for the field is "Date"

So, I'm going to assume that the dates in SQL server are based on eastern US time.  So that means you need to do something like this.

DailyTask.TaskDate = ConvertDateTimeToDate(AddHours(ConvertDateToDateTime(CurrDate(),-5))

(I do not have access to my environment so the syntax may not be correct but you should get the idea.)

Curt


Solution

I think there is a easier way to do that does not require any knowledge of what is the user timezone.

Try this:

- Create a local variable in your screen of type Date

- Set the default value of that variable to CurrDate()

- In your aggregate, instead of using the CurrDate use the variable that you just created.


This assumes that the dates and times that are stored in the server are already representing the same timezone as the end user. That is what it appears from what was said in this post, but im assuming a bit since its not clear how those values were created.


Regards,

João Rosado

Solution

This will not solve the problem.  CurrDate() and CurrDateTime() are always the server date and time, never the user date and time.  Setting a variable to CurrDate() is no different than just using CurrDate().  Unless you know the users timezone and therefore the offset AND you know how the dates are set within the data (and that method is constant), there will always be challenges in doing this type of query.

Curt


Not really, saying that both functions always return server information is not true. It all depends on where the code is running.

If its a Mobile application then a default variable of a screen will be evaluated in javascript in client side and then sent to the server without conversions (because there are no conversions on "Date").


Regards,

João Rosado

Thank you both for the help. I made the changes to test. I created a local Variable "TodayIs" and set it to CurrDate() in my "onInitiate" action. Will see if it works after 7 pm today.

Thanks,

Gonzalo

Joao,


Your solution worked!! thanks you both for the help.

HI Gonzalo and Joao

Can you help me by giving a screenshot how to solve your problem?

Thanks

Hi Imas,


Is your problem exactly the same?

Maybe its easier (and more accurate) if you show us first what you have now.


Regards,

João Rosado

Hi Joao,

Not exactly,

My case is i am trying to retrieve data from response like below.


When i take it directly with this function.

Date changed to +1 days. Not the same as I took

Can you give me the solution?


Thanks

Don't think the above workaround is useful in this case as your scenario is very different.

Continuing this in the other thread that you created.


Regards,

João Rosado