How do you actually use this element?

[mercmobily]

I need to store a field with date/time on the DB, and retrieve them. I am using MySql as my DB backend. I would ideally store the date/time as timestamp on MySql; I would probably prefer to store the timestamp as a BIGINT (if I have to include the milliseconds, although I don't need them) or INT (if I can get datetime-picker to return me a straight Unix timestamp)

Now... when I load data in JSON, I get:

{
  eta: 1523466123000
}

I am trying to use the element like this:

 <datetime-picker auto-confirm required id="eta" name="eta" value="[[info.eta]]" label="ETA *"></datetime-picker>

Where info obviously contains the JSON result. Note that I only want one-way binding as I don't want info to change in real time -- I will update info once the record has been submitted via AJAX to the server, according to the server's response.

So, my question is: how do I actually do this?

The simplest use-case with setting value:

https://codepen.io/anon/pen/mLrVXg

Doesn't seem to work. Using the element as "write-only" works really well: its value is a Unix timestamp which gets submitted to the server without any trouble. However, when I try to load the record (as shown in the codepen), it just won't get set.

How do I do that? Why doesn't the element set its value when I set value?

[mercmobily]

I am trying pretty much every possible combination. If I do:

 <datetime-picker auto-confirm required id="eta" name="eta" datetime="[[_ts(info.eta)]]" value="[[info.eta]]" label="ETA *"></datetime-picker>

With _ts() being:

_ts (s) {
    if (s) return new Date(s).toISOString()
  }

I end up with a value (which is good) in the wrong timezone (which is really bad). For example, since I am in GMT+8, 1522947723000 should give me an input form for Friday, 6 April 2018 01:02:03 whereas I get an input form for Thursday, 5 April 2018 17:02:03.

Hints?

[fooloomanzoo]

if you are using polymer, then you should not use the double-square-bracket for databinding, you should use the double-mustache-brackets for achieving databinding. As I was saying about timezones in your other issue, if you give a timezone in one of the preset values, this timezone will be initially used, nonetheless you set it manually. Setting the datetime by a number should not break the element, but still there is no timezone in the number representation. But setting the datetime initially got a mistake, like said in your other issue, and should also take the local timezone, so to clear that we will use your other issue.

[mercmobily]

Hi,

I found your answer very confusing.

if you are using polymer, then you should not use the double-square-bracket for databinding, you should use the double-mustache-brackets for achieving databinding

Using square or curly brackets depends on what you are trying to achieve. In my case, I want one-way data binding because I will end up changing info manually once the server responds. In any case, the use of square or curly data binding by the container should be totally transparent to your element.

As I was saying about timezones in your other issue, if you give a timezone in one of the preset values, this timezone will be initially used, nonetheless you set it manually.

I didn't "give" any timezone information. My browser (and therefore the Javascript engine) knows what timezone I am in (in this case, UTC+8) and will render the "string" version of the date (as well as the translation to what time, what day, etc.) depending on the timezone. However, that is (and it should be) totally transparent to me. Date objects store, internally, a Unix timestamp regardless. The iso string doesn't include a timezone since I am using toISOString which is always relative to UTC (as per documentation). I am finding very hard to make sense of your sentence - sorry.

Setting the datetime by a number should not break the element, but still there is no timezone in the number representation.

Correct. And yet, it does: I am passing an ISO string to the datetime property of your element, and am seeing a set value that is not relative to my timezone. This is essentially a bug -- don't you agree? What I mean is, having this:

<datetime-picker auto-confirm required id="eta" name="eta" datetime="2018-04-05T17:02:03.000Z" label="ETA *"></datetime-picker>

OUGHT to create, internally to your element, a timezone with timestamp 1522947723000 -- which, then, when showing the element to the user for input, should consider the timezone the user is in -- which should be 100000% automatic if you use standard Javascript functions to get info out of the Date object (in my case, Fri Apr 06 2018 01:02:03 GMT+0800 (AWST)).

But setting the datetime initially got a mistake, like said in your other issue, and should also take the local timezone, so to clear that we will use your other issue.

I assume you are confirming what I wrote above?

Incidentally, after a number of attempts, I came out with a proper solution (!):

<datetime-picker timezone auto-confirm required id="eta" name="eta" datetime="[[_ts(info.eta)]]" value="[[info.eta]]" label="ETA *"></datetime-picker>

_ts (s) { if (s) return new Date(s) }

Basically, feeding datetime a date object already created correctly, has the effect of getting the element to display the CORRECT date/time (!). To conclude, the element seems to have TWO issues:

• Setting the value alone as a timestamp will NOT have a proper effect on the element
• Passing an ISO string to datetime gets the element to display the wrong information (that is, the time as passed to the string, RATHER THAN the time relative to the browser's timezone).

Right?

Merc.