1. #11
    Sencha User
    Join Date
    Jan 2008
    Posts
    46
    Vote Rating
    0
    theyang is on a distinguished road

      0  

    Default


    Ok here is my simple solution:

    Code:
        function convertDate(v, mix) {
            return new Date(parseFloat(v.slice(6, 19))).toLocaleString();
        }
        
        var contentStore = new Ext.data.WCFJsonStore({
            url: 'Services/ContentManagementService.svc/getContents',
            baseParams: { channelSlug: '' },
            fields: ['Title', { name: 'DateModified', convert: convertDate }, 'ModifiedBy', { name: 'DateCreated', convert: convertDate }, 'CreatedBy']
        });
        contentStore.load();
    As long as the server is set to same time zone and region (sure it will be), there will be no problems with this code.

    Thank you all for the tips.

  2. #12
    Ext User dotnetCarpenter's Avatar
    Join Date
    Mar 2007
    Location
    Copenhagen, Denmark
    Posts
    271
    Vote Rating
    0
    dotnetCarpenter is on a distinguished road

      0  

    Default


    How will you make sure that your users will have the same timezone?!? Most people don't even know about it. I know this from bitter experience. Please don't do the same mistake.

    The Ext.data.WCFJsonStore looks interesting. Do you mind posting it here?

  3. #13
    Sencha User
    Join Date
    Jan 2008
    Posts
    46
    Vote Rating
    0
    theyang is on a distinguished road

      0  

    Default


    The web application is for internal use and all the users are on the same domain, so I am pretty sure about the time zone.

    There is nothing special about the WCFJsonStore. It is just set up for WCF responses, the root property is set to "d" for all requests (the root for all WCF services that have webscripting behavior)

  4. #14
    Sencha User
    Join Date
    Oct 2007
    Location
    Orlando, FL
    Posts
    19
    Vote Rating
    0
    wadebee is on a distinguished road

      0  

    Arrow Trying To Understand dotNetCarpenter suggestion

    Trying To Understand dotNetCarpenter suggestion


    @dotNetCarpenter: Are you suggesting that I should change the public signature of my object properties from DateTime to string? For example:

    private DateTime _myDateTime=DateTime.Now;

    [DataMember(Name="JsonFieldName")]
    public string MyDateTime {
    get{return _myDateTime.ToString("yyyy-MM-dd hh:mms");}
    set{_myDateTime = DateTime.Parse(value);
    }


    This may work but seems very clumsy to modify the type safety of your business layer to accomodate the serialization issues of the client? You mention timezone issues. Can you explain how a public string signature will correct a problem with a public DateTime signature? It seems to me the problem is in the parsing of Microsoft's proprietary Json date format ("\/Date(1069689066000-0500)\/") Most of us .Net coders are using higher level WCF classes or going straight to the DataContractJsonSerializer class and stuck with this Json date format unless we want to tackle custom serialization. The following is how I serialize all my output with .NET 3.5 framework...

    Code:
               
    DataContractJsonSerializer   serializedObject                = null;
    MemoryStream                   serializedObjectStream      = new MemoryStream();
    string                               serializedObjectString        = string.Empty;
    
    // Serialize this object into a MemoryStream
    serializedObject = new DataContractJsonSerializer(this.GetType(), this.GetType().Name);
    serializedObject.WriteObject(serializedObjectStream, this);
    serializedObjectString = Encoding.Default.GetString(serializedObjectStream.ToArray());
    serializedObjectStream.Close();
    return serializedObjectString;
    }

  5. #15
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,483
    Vote Rating
    35
    Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    I always send dates as milliseconds since 01/01/1970 00:00:00 then there's no ambiguity. It's a point in time. How it is displayed depends upon where the displayer is located, but it is the correct point in time.

  6. #16
    Ext User dotnetCarpenter's Avatar
    Join Date
    Mar 2007
    Location
    Copenhagen, Denmark
    Posts
    271
    Vote Rating
    0
    dotnetCarpenter is on a distinguished road

      0  

    Default


    @wadebee
    What you have outlined is exactly what I suggest. That way it doesn't matter if the client machine is set to a wrong timezone. If you keep the normal DateTime formatting you will get a JavaScript date object with timezone. When the user sees the date or time it will display that corresponded to her timezone (like Animal said). This is usually not what you want. If your application is a booking app, e.g. for a hairdresser. You don't want the client to book a time at 1 pm and then have the booking automatically changed to 11 am, if the client machine is set to a wrong timezone. There is no easy way of detecting this but if you just use strings, you're clear. I hope that clarifies what I mean.

    Cheers, Jon.

    BTW, why do you explicit serialize the object?
    no - I do not check my PMs that often
    but I do answer

  7. #17
    Sencha - Community Support Team mystix's Avatar
    Join Date
    Mar 2007
    Location
    Singapore
    Posts
    6,236
    Vote Rating
    4
    mystix will become famous soon enough

      0  

    Default


    @wadebee,

    if you really want to / have to use m$'s serialized date format, you could try the override i posted here to handle m$ dates as detailed in this blog post: http://weblogs.asp.net/bleroy/archiv...-and-json.aspx. (note though that that override expects (hacky) m$ dates of the form "\/Date(1069689066000)\/")

    i agree with Animal though -- it's much safer for the server to send an unambiguous unix time, and let the client deal with the datetime conversion.

  8. #18
    Ext User dotnetCarpenter's Avatar
    Join Date
    Mar 2007
    Location
    Copenhagen, Denmark
    Posts
    271
    Vote Rating
    0
    dotnetCarpenter is on a distinguished road

      0  

    Default


    It's just that UTC time doesn't work consistently across browsers. You have to be sure that your users have updated their browsers or have correct timezone (which they don't know about) and doesn't have the wrong date set (which they have).

    In other words - just use a string.

    Code:
    // deserialize a Microsoft JSON date to a JavaScript date
    var exp = data.replace(new RegExp('(^|[^\\\\])\\"\\\\/Date\\((-?[0-9]+)\\)\\\\/\\"', 'g'), "$1new Date($2)");
    no - I do not check my PMs that often
    but I do answer

  9. #19
    Ext User
    Join Date
    Mar 2009
    Posts
    5
    Vote Rating
    0
    aplnas is on a distinguished road

      0  

    Post


    Quote Originally Posted by dotnetCarpenter View Post
    It's just that UTC time doesn't work consistently across browsers. You have to be sure that your users have updated their browsers or have correct timezone (which they don't know about) and doesn't have the wrong date set (which they have).

    In other words - just use a string.

    Code:
    // deserialize a Microsoft JSON date to a JavaScript date
    var exp = data.replace(new RegExp('(^|[^\\\\])\\"\\\\/Date\\((-?[0-9]+)\\)\\\\/\\"', 'g'), "$1new Date($2)");
    I tried to use this code and it doesn't work.
    Imagination is more important than knowledge.

  10. #20
    Sencha - Community Support Team mystix's Avatar
    Join Date
    Mar 2007
    Location
    Singapore
    Posts
    6,236
    Vote Rating
    4
    mystix will become famous soon enough

      0  

    Default


    Quote Originally Posted by aplnas View Post
    I tried to use this code and it doesn't work.
    see post #17.

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar