Question about DateTime

[martintaal]

Hi, one question, I have a particular (absolute) DateTime component where I need that if the received json is something like:

myDateTime: '13-02-2014T15:30:00'

and then, I need that the drawn DateTime input renders

13-02-2014 15:30:00

and in case of changing it and the form is saved it returns the displayed value to the server.

The problem that I have, is that it seems that Smartclient seems that expects that what I receive is an UTC and it is returning an UTC also, so I am viewing (in a GMT+2 timezone):
13-02-2014 17:30:00

Note that I have another DateTime components that I need to behave with the UTC conversion, so I can have two kinds of DateTime in a form (the default one and the absolute one).

Do you have any suggestion in how can I handle the absolute DateTime that I am building? I have tried without success override the setValue and the getValue, but it seems that the data passes several times through them, so the adjust is not well done.

Thanks

[Isomorphic]

Yes, SmartClient always transmits in UTC and assumes UTC if a datetime value does not specify a timezone. This is widely considered a best practice.

If you need a particular DateTimeItem to display a datetime value in a timezone different from all other datetimes in the app, you want to implement a formatEditValue and parseEditValue that handles this.

Never try to override getValue() and setValue() - the documentation on these methods does not describe when these methods are called by framework code, so if you attempt an override you're relying on undocumented functionality. The same is true of any other method in the system that doesn't describe when it is called.

[martintaal]

Thanks, it works ok in the form view. Now the problem is that in the complementary ListGrid that I have with the same datasource, I am still viewing the DateTime with the UTC conversion.

Any idea or suggestion about how can I handle this case?

PS: I am using for this project Smartclient 8.3d but I assume that with 10.0d the result will be the same.

[Isomorphic]

Same approach - define a formatCellValue, and if editing is allowed in the grid, provide a formatEditorValue / parseEditorValue via field.editorProperties.

[martintaal]

Thanks once more time. And a last question: for the case of the isc.Calendar, is there any function to do a similar approach (visualize events without the UTC conversion) or have I to manipulate directly the response of the datasource?

[Isomorphic]

While the same approach would work for customizing the DateTimeItems in the event editor, the main Calendar display doesn't have an ability to display different events in different timezones, so yes you would have to manipulate the data at the DataSource level.

[martintaal]

For the case of the isc.Calendar, all the events will should have the same absolute datetime value as it is retreived from the dataSource, so no mixed events: all of them without the UTC adaptation.

I don't know if this fact changes your answer or if it is the same: I need to manipulate directly the returned data.

Thanks

[Isomorphic]

We're not sure what you mean about the "UTC adaptation". The time value you showed ('13-02-2014T15:30:00') is ambiguous, so as previously discussed, we assume UTC.

You can add an explicit timezone to make the time value no longer ambiguous.

Interpreting this text as a datetime value all happens at the DataSource layer. The Calendar then displays time according to the browser timezone or your setting for defaultDisplayTimezone.

[martintaal]

'13-02-2014T15:30:00' is ambiguous and Smartclient assumes it as UTC, I agree, but I want it to be assumed as "This is a Datetime in the browser's timezone". I cannot provide the timezone since the server which is sending it doesn't know the client's timezone.

We call this kind of datetime "Absolute DateTime", because the value you see is exactly the same in the database, in the server and in the client, independently of its configured timezone. This is the kind of DataTimes that could be used, for example, for a flight reservation, where you always see (and save) the same date+time independently of your client configured timezone.

Setting "defaultDisplayTimezone" is not an option neither, because in many other places I need the default behavior (assume that the received datetime is UTC).

So, then, if the isc.Calendar doesn't have this option to interpret an absolute datetime, neither have the option to parse somehow the events' startTime and endTime, I will have to do something like:

eventStartTime = new Date(eventStartTime.getTime() - (eventStartTime.getTimezoneOffset() * 60000));

when reading events and

eventStartTime = new Date(eventStartTime.getTime() + (eventStartTime.getTimezoneOffset() * 60000));

when saving them.

[Isomorphic]

You're getting a bit confused and need to revisit the Date and Time Format and Storage overview.

In particular:
1. There's no such thing as an "Absolute DateTime": if you are rendering days, hours and seconds, it's in *some* timezone.

2. SmartClient interprets datetime strings with no timezone indicator as UTC. The defaultDisplayTimezone setting then influences what timezone is used when rendering the datetime value for the user. It doesn't affect how a DataSource interprets datetime strings in a JSON or XML response.

Please consider these points and make a second attempt to explain what you want (currently it does not actually make sense).

[martintaal]

Let me try with an example.

Imagine that I have a Postgres database with these three tables:

NYC_JFK_FLIGHTS_DEPARTURES
  Record 1: 
    Departure_Time: '2014-02-13 10:23:00' (timestamp without timezone)
    Flight_Duration: '2' (integer)
  Record 2:
    Departure_Time: '2014-02-13 15:30:00' (timestamp without timezone)
    Flight_Duration: '3' (integer)
  Record 3:
    Departure_Time: '2014-02-13 20:55:00' (timestamp without timezone)
    Flight_Duration: '1' (integer)

LA_LAX_FLIGHTS_DEPARTURES
  Record 1: 
    Departure_Time: '2014-02-13 09:17:00' (timestamp without timezone)
    Flight_Duration: '4' (integer)
  Record 2:
    Departure_Time: '2014-02-13 17:45:00' (timestamp without timezone)
    Flight_Duration: '3' (integer)
  Record 3:
    Departure_Time: '2014-02-13 19:10:00' (timestamp without timezone)
    Flight_Duration: '2' (integer)

PARIS_ORLY_FLIGHTS_DEPARTURES
  Record 1: 
    Departure_Time: '2014-02-13 05:10:00' (timestamp without timezone)
    Flight_Duration: '2' (integer)
  Record 2:
    Departure_Time: '2014-02-13 11:50:00' (timestamp without timezone)
    Flight_Duration: '3' (integer)
  Record 3:
    Departure_Time: '2014-02-13 20:10:00' (timestamp without timezone)
    Flight_Duration: '2' (integer)

Note that "timestamp without timezone" is a valid PostgreSQL column type: http://www.postgresql.org/docs/9.0/i...-datetime.html section 8.5.1.3



Now I have a web portal developed with Smartclient. In this portal there are three isc.Calendar widgets.

In the first, called "NYC JFK Flights" I need to have the following events
Event 1: a box that starts from "10:23:00" and ends in "12:23:00"
Event 2: a box that starts from "15:30:00" and ends in "18:30:00"
Event 3: a box that starts from "20:55:00" and ends in "21:55:00"

In the second, called "LA LAX Flights" I need to have the following events
Event 1: a box that starts from "09:17:00" and ends in "13:17:00"
Event 2: a box that starts from "17:45:00" and ends in "20:45:00"
Event 3: a box that starts from "19:10:00" and ends in "21:10:00"

In the third, called "Paris Orly Flights" I need to have the following events
Event 1: a box that starts from "05:10:00" and ends in "07:10:00"
Event 2: a box that starts from "11:50:00" and ends in "14:50:00"
Event 3: a box that starts from "20:10:00" and ends in "22:10:00"

The startDate it is clear that it is the Departure_Time, and the endDate is the Departure_Time + Flight_Duration, so my server send a xml to the client like:

{
...
startDate: '2014-02-13T10:23:00'
endDate: '2014-02-13T12:23:00'
...
},{...}...

If I do this with Smartclient, I am not going to see the events in these time positions, because they are going to be transformed according to my client PC timezone. I don't want this. The visualization of this web portal should be always the same, independently of my client PC timezone.

I hope that with this example you can have better understanding about the problem that I am facing.

Notes:
* I cannot set the "defaultDisplayTimezone" in the client side, because there are other places where I am using DateTime inputs (among other components) where I want to preserve the standard logic (interpret the received datetime as an UTC datetime)
* The server doesn't know the client timezone, so it cannot hack the sent startDate and endDate to ensure that the datetimes after the UTC interpretation be what they need to be.

[Isomorphic]

There *is* such a thing as a datetime value without a timezone, such as Unix epoch time (number of milliseconds since Jan 1 midnight 1970 UTC). But when you render a datetime value as a String showing day, hour and minutes, there is no way to turn such a String back into a Java or JavaScript Date instance, whose internal value is an epoch time, without assuming a timezone. This is true of any system, not just SmartClient - a timezone must be assumed in order to arrive at an epoch time value.

And again the timezone we assume when parsing JSON (if you don't specify one) is UTC. Please read that sentence at least twice! You keep ignoring this:

* I cannot set the "defaultDisplayTimezone" in the client side, because there are other places where I am using DateTime inputs (among other components) where I want to preserve the standard logic (interpret the received datetime as an UTC datetime)

We just told you:

2. SmartClient interprets datetime strings with no timezone indicator as UTC. The defaultDisplayTimezone setting then influences what timezone is used when rendering the datetime value for the user. It doesn't affect how a DataSource interprets datetime strings in a JSON or XML response.

So once again, defaultDisplayTimezone has no effect on how datetime Strings in JSON are interpreted.

Likewise:

* The server doesn't know the client timezone, so it cannot hack the sent startDate and endDate to ensure that the datetimes after the UTC interpretation be what they need to be.

This is nonsense. The server does not need to know the client's timezone in order to send a datetime value intact because the timezone used for parsing is always UTC.

So you have a 100% reliable and unambiguous way to get the exact Date objects you want - specifically the exact epoch time value you want - without the server needing to know anything about the client.

From there, because you want to render times in multiple different timezones on the same page, you will need to add offsets to the times so that they are displayed as the time you intended even though the Calendar is placing events based on the defaultDisplayTimezone.

[martintaal]

From there, because you want to render times in multiple different timezones on the same page, you will need to add offsets to the times so that they are displayed as the time you intended even though the Calendar is placing events based on the defaultDisplayTimezone.

My original question was if I have to add these offsets by parsing the datasource or if there exist any function to do it.


Anyway, another question. I have successfully managed the formatEditorValue / parseEditorValue in the DateTimeItem. But now I have to do the same with TimeItem, but it seems that these functions are not present in the TimeItem. Any idea about how can I do it?

Thanks

[Isomorphic]

What does "parsing the datasource" mean?

Both TimeItem and DateTimeItem extend FormItem, which is where formatEditorValue and parseEditorValue are introduced.

[martintaal]

What does "parsing the datasource" mean?

That if my browser, for example, has a GMT+2, and I receive from the server this:

{
...
startDate: '2014-02-13T10:23:00'
endDate: '2014-02-13T12:23:00'
...
}

And I want to avoid they be converted to
startDate: '2014-02-13 12:23:00+02:00'
endDate: '2014-02-13 14:23:00+02:00'

I will have to parse the DataSource response to substract two hours (the client timezone) to the received dates, in order to be able to see the event starting at 10:23:00 and ending at 12:23:00

Both TimeItem and DateTimeItem extend FormItem, which is where formatEditorValue and parseEditorValue are introduced.

Fixed, I had a typo.