Support unix time instead of plain JS Date object #190

alexandernst · 2015-07-13T14:19:48Z

No description provided.

alexandernst · 2015-07-13T14:22:51Z

I can provide a PR for this if you'll accept it. If you want me to do it in a specific way, please say so. @dalelotts

alexandernst · 2015-07-20T07:07:29Z

dalelotts · 2015-07-21T23:41:02Z

Unix time does not have timezone info. Do you have a suggestion about how to handle the lack of timezone info in this case?

alexandernst · 2015-07-21T23:56:05Z

@dalelotts You don't. If developer want's to use unix time, he/she (most probably) will be aware of that and will know how to handle himself/herself this situation.

dalelotts · 2015-07-22T00:32:21Z

Possibly. It's hard to know all of the use cases. I have avoided this type of change because it is often connected to a sub-optimal implementation where time zone handling is not well thought out, which is the opposite of what you are suggesting. Can you give me some more detail on your use case?

alexandernst · 2015-07-22T00:38:11Z

@dalelotts MongoDB's DateTime() is actually unixtime. A simple REST with Angular on the client side will pull unix time from the database.

Now, I could intercept the unix time and convert it to what this library expects, but then I'd have to add yet another callback for when this library modifies the date (convert back to unix time). The entire thing feels a little bit dirty, as this could be a lot easier if I could just pass the model as-is to this library.

alexandernst · 2015-07-25T14:57:18Z

@dalelotts Any news on this one? What do you think? Could this be implemented?

…g data in the model Accepts any string value, but the following values have special meaning (these values are case sensitive) : * ```'Date'``` stores a Date instance in the model. Will accept Date, moment, milliseconds, and ISO 8601 strings as initial input from the model * ```'moment'``` stores a moment instance in the model. Accepts the same initial values as ```Date``` * ```'milliseconds'``` store the epoch milliseconds (since 1-1-1970) in the model. Accepts the same initial values as ```Date``` -Any other value is considered a format string. -When accepting values from, and saving values to the model, this directive tries to be as flexible as possible. Dates, moments, and milliseconds are all accepted as input no matter what you specify for ```modelType```. However, strings are problematic and often lose timezone information, so use caution when storing strings. -If you must use a string, be aware that the format stored in the model must exactly match the format specified in ```modelType```. For example, the value in the model is ```'2015-12-31'``` then using ```modelType: 'MM-DD-YYYY'``` will cause an exception. -I predict that I will regret adding this feature. closes #241, closes #190, closes #39

jhammersholt · 2015-12-22T10:02:47Z

Here is how i solved something similar

I just added this to the directive

ngModelController.$parsers.push(function(data) {
  //convert data from view format to model format
  if (data) {
      return moment(data).format('DD-MM-YYYY HH:mm');
  } else {
      return data;
  }
});

ngModelController.$formatters.push(function(data) {
    //convert data from model format to view format
    if (data) {
      return moment(data, 'DD-MM-YYYY HH:mm');
    } else {
        return data;
    }
});

I also had to change all var ActiveDate (or format) to use ngModelController.$viewValue instead of ngModelController.$modelValue for active to work
using moment library you have already included
what is left I guess is to make that format configurable

arunthilak · 2016-01-25T22:59:08Z

@jhammersholt - Do you have a commit or fork which I could use?

arunthilak · 2016-01-25T23:00:25Z

@dalelotts - Hi, do you know when you can get this done ?

Many Thanks!

dalelotts · 2016-01-26T03:27:45Z

@arunthilak Have a look at the code in the develop branch - it adds modelType allowing you to store milliseconds (utc) - unix time is seconds but that would be easy enough to add as a modelType.

I have not released this code to production yet due to the fact that I have not had anyone volunteer to test all of the new modelTypes. Check them out and let me know how it works for you.

arunthilak · 2016-01-27T01:25:07Z

@dalelotts - Thank you for your develop branch. I tested it out and I am able to get epoch values directly in the ngmodel value. Well, it's kind of what I want. I think i misunderstood this feature request. I need to display the user friendly string date in the view after selection, but have the epoch in the model value, behind the scenes; you know when submitting the json to a server. Or vice versa - i.e. when server sends epoch, display the User Friendly date in the text box.
Am just learning directives, so finding it difficult to get it right.
Just have another question though - is attribute 'display' incompatible when epoch is selected as modelType?

Many Thanks,
Arun Thilak

dalelotts · 2016-01-27T01:51:30Z

Maybe you can setup a fiddle, plunder, or jsbin example that I can look at.

On Tuesday, January 26, 2016, arunthilak [email protected] wrote:

@dalelotts https://github.com/dalelotts - Thank you for your develop
branch. I tested it out and I am able to get epoch values directly in the
ngmodel value. Well, it's kind of what I want. I think i misunderstood this
feature request. I need to display the user friendly string date in the
view after selection, but have the epoch in the model value, behind the
scenes; you know when submitting the json to a server. Or vice versa - i.e.
when server sends epoch, display the User Friendly date in the text box.
Am just learning directives, so finding it difficult to get it right.
Just have another question though - is attribute 'display' incompatible
when epoch is selected as modelType?

Many Thanks,
Arun Thilak

—
Reply to this email directly or view it on GitHub
#190 (comment)
.

Sent from Gmail Mobile

arunthilak · 2016-01-27T18:54:00Z

Here is a plnkr link: http://plnkr.co/edit/nNpfhewxc3BH5NVoFSes?p=preview
I have not found a date widget that allows seamless converting between the date that is displayed on the screen and data that is saved to a data source.
Thank you so much for looking into this.

dalelotts · 2016-01-28T06:57:46Z

My other directive, angular-datetime-input gets you mostly to where you want to be.

See http://plnkr.co/edit/Nv7rpxPAJ2ud3O0ySHCm?p=preview

The only remaining issue is that the stored data is in milliseconds UTC and has no timezone information, so when it is formatted by the angular-datetime-input directive it is UTC. (this is by design for this directive)

Do you want to store the time values as UTC or local time?
Do you want to display the time values in UTC or local time?

dalelotts · 2016-01-28T06:59:43Z

Oh, and one added benefit of the datetime-input directive is that the user can type in the date if they like, and it can accept multiple format, thus allowing the user to enter the date in the format they like best...but it will display is the format you specify

arunthilak · 2016-01-28T19:27:26Z

@dalelotts - Ohh.. awesome thank you so much !!! I am building some apps using elasticsearch and opentsdb. The timestamps I need to send to the servers are always in GMT, so this works for me.

Many Thanks,
Arun Thilak

arunthilak · 2016-02-01T19:25:07Z

@dalelotts : While using this we realized how we could deal with the timezone, which of course is not stored with the epoch. You can have the option to either display the time in Local Time (of browser) or UTC.

dalelotts · 2016-02-01T19:36:29Z

Great! Is there an example you can share about how you did it?

arunthilak · 2016-02-03T23:37:25Z

Hi Dale,
Here is an example - but it does have some bugs and I need your help in
fixing it.
http://plnkr.co/edit/2roEbIyVpQ7s5qnjNC0w?p=preview

If you notice Example 2 - If we pass millisecond data type, it correctly
shows the View in Local Time Zone, and we can toggle between UTC and LOCAL
for the view. But the problem for this one is that the Dropdown Datepicker
is all in UTC. So if I select 10 AM, it assumes it as UTC and View Value is
updated as 2 AM.

On other hand in Example 1 - if we select a particular date, say 11 AM, it
correctly displays as 11 AM and model value is correctly updated as 18
hours. But, if I select the dropdown again, it thinks the active time is in
UTC.

Am sorry, if I messed it up, but can you please help me figure out how I
can synchronize the "View TimeZone" with the "dropdown datepicker TimeZone"
and abstract it away from "model TimeZone".
Is it possible to bundle these two javascripts together in order to clearly
abstract model and view and tie the view with the dropdown datepicker?

Many Thanks,
Arun Thilak

On Mon, Feb 1, 2016 at 11:41 AM, Dale Lotts [email protected]
wrote:

Great! Is there an example you can share about how you did it?

—
Reply to this email directly or view it on GitHub
#190 (comment)
.

Arun Thilak
www.nanmai.org
“You see things; and you say, 'Why?' But I dream things that never were;
and I say, 'Why not?'”
- George Bernard Shaw

dalelotts · 2016-02-04T12:35:33Z

@arunthilak, your example makes sense. That's the issue I was mentioning earlie. I'm not sure what the most common use case is for milliseconds - UTC all the time, or UTC in the model and local time in the UI. I suspect the later.

arunthilak · 2016-02-05T17:59:02Z

@dalelotts - Yes, totally agree .. UTC in the model and Local time in the UI is the most useful case. So the problem that I am having now is that, I am unable to figure out how to pass Local time to the dropdown calendar (Or how to toggle between UTC and LOCAL for dropdown). How can we synchronize the dropdown calendar Time Zone with View Time Zone, rather than the model Time Zone.

Many Thanks,
Arun Thilak

dalelotts · 2016-02-06T00:43:43Z

Good question. I think this will require a change to have the model and the UI in different time zones.

As a work around, you can use the set-time callback to set the "real" UTC value in the model, but drive the UI off of a an ignored property in the model that stores the local time.

arunthilak · 2016-02-12T01:24:03Z

Thanks again. As you suggested I was able to fix the issue in set-time
function. Now am able to get input and drop down in local timezone and
model in milliseconds. Seems to work fine for me. You could probably verify
or validate.

http://plnkr.co/edit/kWBklqTmTgBlbaXgOgcV (Example 2)

Lines 492-496 that I changed are in set-time function:

            case 'milliseconds':
            newDate = moment(newDate);
            newDate.local();
              newDate = newDate.valueOf();

Many Thanks
Arun Thilak

On Fri, Feb 5, 2016 at 4:43 PM, Dale Lotts [email protected] wrote:

Good question. I think this will require a change to have the model and
the UI in different time zones.

As a work around, you can use the set-time callback to set the "real" UTC
value in the model, but drive the UI off of a an ignored property in the
model that stores the local time.

—
Reply to this email directly or view it on GitHub
#190 (comment)
.

Arun Thilak
www.nanmai.org
“You see things; and you say, 'Why?' But I dream things that never were;
and I say, 'Why not?'”
- George Bernard Shaw

dalelotts added the Thinking label Jul 21, 2015

dalelotts closed this as completed in 11e6cb2 Jan 31, 2016

Support unix time instead of plain JS Date object #190

Support unix time instead of plain JS Date object #190

Comments

alexandernst commented Jul 13, 2015

alexandernst commented Jul 13, 2015

Uh oh!

alexandernst commented Jul 20, 2015

Uh oh!

dalelotts commented Jul 21, 2015

Uh oh!

alexandernst commented Jul 21, 2015

Uh oh!

dalelotts commented Jul 22, 2015

Uh oh!

alexandernst commented Jul 22, 2015

Uh oh!

alexandernst commented Jul 25, 2015

Uh oh!

jhammersholt commented Dec 22, 2015

Uh oh!

arunthilak commented Jan 25, 2016

Uh oh!

arunthilak commented Jan 25, 2016

Uh oh!

dalelotts commented Jan 26, 2016

Uh oh!

arunthilak commented Jan 27, 2016

Uh oh!

dalelotts commented Jan 27, 2016

Uh oh!

arunthilak commented Jan 27, 2016

Uh oh!

dalelotts commented Jan 28, 2016

Uh oh!

dalelotts commented Jan 28, 2016

Uh oh!

arunthilak commented Jan 28, 2016

Uh oh!

arunthilak commented Feb 1, 2016

Uh oh!

dalelotts commented Feb 1, 2016

Uh oh!

arunthilak commented Feb 3, 2016

Uh oh!

dalelotts commented Feb 4, 2016

Uh oh!

arunthilak commented Feb 5, 2016

Uh oh!

dalelotts commented Feb 6, 2016

Uh oh!

arunthilak commented Feb 12, 2016

Uh oh!