Date Time Component - secondsUntil Using Local Time Instead of UTC

[sid]

Wappler Version : 3.4.0
Operating System : Windows 10

Expected behavior

Using date format functions such as secondsUntil, should calculate seconds remaining from the parameters passed.

Actual behavior

When supplying a date time component set to UTC Time, the secondsUntil function calculates the value using local time.
Even using the toUTCDate() function does not make a difference.

How to reproduce

<dmx-datetime id="dateTimeNow" utc="true"></dmx-datetime>

1. Date Time component with UTC Time enabled.
2. Result of secondsUntil function.
3. Value of date time param supplied to calculate seconds (which is a UTC date time).

What I have tried:

1. Remove the UTC time check and use it directly. Response is same as what I am getting right now, but that is expected and correct.
2. Add toUTCDate() function to date time component and the parameter both. Result is still seconds calculated using local time which is incorrect.

Using ASP.NET, but not sure if this is server model specific since this is a client side function.

[sid]

Hi @patrick.
Can you please take a look at this? The temporary workaround I have put in is not very good. Would like to use Wappler’s function.

[patrick]

Date Time is always in local time, the toUTCDate() formatter doesn’t change the date/time, it only formats it in the UTC format. It is how the Date object in JavaScript works and how it works in most languages.

[sid]

Damn.
So even if I do dateTimeNow.datetime.toUTCDate().secondsUntil(....), the seconds until function will still run on the local time?

[patrick]

You compare the difference of 2 dates, what do you pass in the secondsUntil? If it is an date string in UTC format then it also get converted to the local time.

Converting to UTC date is only needed when you communicate with the server and have to manage different time zones. Normally on the client-side you just work in the client time zone. Also when you get a date from the server, when it isn’t in UTC format, it will be handled as local time, UTC formatted date strings will always be adjusted to local time.

[sid]

@patrick

If it is an date string in UTC format then it also get converted to the local time.

Damn. Tough luck. Will have to create a custom formatter looks like.

@patrick

Normally on the client-side you just work in the client time zone

That is right. But the current use case has time bound action. And the time form DB is UTC, and I need to count-down using seconds until - hence need UTC on client side too.

@patrick

Also when you get a date from the server, when it isn’t in UTC format, it will be handled as local time

This is basically the case here I think. There is no time zone component in the date time I am getting from DB. Is this something that is a better practice? Because in all the years I have coded so far, I have never really stored the time zone (mostly because I've never built anything that plays with time zones) in date time column.

[patrick]

It all depends on how you use the date.

Situation 1:
You want to use the exactly as inserted. For example you insert 2020-10-22 12:30:00 and you want to have it show exactly this for each user, so no conversion of timezone. In this case you should just use local time, no UTC. You submit the date as local time to the server, store it as local time and send it back to the user as local time. No conversions are done.

Situation 2:
You want to show the date in the timezone of the user. In this case you will need to use the UTC format to communicate. On the server you may store the date as local date in the database, but you have to send it to the client UTC formatted. On the client it is then automatically converted to the clients local timezone.
Example: Your server is located in New York (timezone -5h) and store a date in the database with NOW. It stores the date as 2020-10-22 05:30:00. You need to send this to the client as UTC date and use the toUTCTime() and it returns as 2020-10-22T10:30:00Z. The client is in Central Europe (timezone +2h). The date for him will then be 2020-10-22 12:30:00 in local time.

UTC format is only used to transfer the date between timezones, within the client or server it just uses its local time.

[sid]

Thanks for the explanation. Did not follow this point though:

@patrick

You need to send this to the client as UTC date and use the toUTCTime() and it returns as 2020-10-22T10:30:00Z

My DB/Web server's timezone is New York. So doing a NOW stores 05:30:00, which is just New York Time local value.
Do I convert it to UTC when I return it to client? In the query itself?
Because if I just send the value as is, will it not just assume that 05:30:00 is Central Europe (local time) and doing a toUTC will return 03:30:00?

[patrick]

We should probably add on options to the database actions on how to return dates. I believe that in most cases they are returned as local time and you have to convert them yourself in an action step.

[sid]

That would be a great option to have and make time zone changes easier to manage.
Thank you for explaining this.

[Antony]

I’ve just been looking to calculate the local time’s offset from UTC on the client side… thank you both for this post!

I’ve managed to work it out by stripping the Z away from the UTC time…

<dmx-datetime id="local_datetime"></dmx-datetime>
<dmx-datetime id="utc_datetime" utc="true"></dmx-datetime>
<dmx-value id="utc_offset_seconds"></dmx-value>
utc_offset_seconds.setValue(local_datetime.datetime.secondsUntil(utc_datetime.datetime.split('Z')[0]))

For me one hour from UTC, it returns me -3600!

I set it once on page load, so it is not being continually updated every second to the same value.