Error when trying to mark a record as Inactive

ERROR ServiceStack.ServiceHost.DtoUtils - ServiceBase<TRequest>::Service Exception
ServiceStack.Common.Web.HttpError: Date Inactive cannot be set to a date in the future. ---> ServiceStack.Common.Web.HttpError: Date Inactive cannot be set to a date in the future.
--- End of inner exception stack trace ---
at HP.HPTRIM.Service.TrimObjectUpdater`1.update(T request, IRequestContext requestContext, Action`1 action)
at HP.HPTRIM.Service.RecordDocumentServiceBase.DoPost(Record request)
at HP.HPTRIM.Service.RecordDocumentService.Post(Record request)
at ServiceStack.ServiceHost.ServiceRunner`1.Execute(IRequestContext requestContext, Object instance, TRequest request)

The client is sending it's current time as the NewInactiveTime on the MakeInactiveAction, but the server rejects it because it's time is different.

Is there a way to handle this, as the client doesn't know what the server's time is ?

Peter

Parents
  • Assuming that the server is using the correct time but a different time zone to the client you would tell the server what GMT Offiset you wish to use for this request.  Use 'gmtOffset' to do this.  gmtOffset maye be sent as a header, query string or form field.  The value should be the number of minutes ahead of GMT, (prefix with a munis sigh of you are behind GMT).

     

    In 83 the option to use the Windows time zone was also introduced.  the ServiceAPI only supports this via the user setting the time zone in the web client user options.  You can set this yourself of course by setting the web client user options via the ServiceAPI.  The advantage of this approach is that daylight saving time is accounted for.

  • It's definitely an odd one - the server and client are on the same timezone and part of the same network.

    It appears as if the client PC is running fast, and doesn't sync with the NTP server as frequently so testing against one server will work sometimes but not others.

    Our development server doesn't exhibit this problem, only the QA server has this problem. I've tried to alleviate the problem by the client sending the time - 1 min.

    Strangely we are now getting an error when marking a record inactive that the "Creation Date" is in the future.

    I'll check the timezone of the client, and set it via the ServiceAPI to see if it makes a difference.

Reply
  • It's definitely an odd one - the server and client are on the same timezone and part of the same network.

    It appears as if the client PC is running fast, and doesn't sync with the NTP server as frequently so testing against one server will work sometimes but not others.

    Our development server doesn't exhibit this problem, only the QA server has this problem. I've tried to alleviate the problem by the client sending the time - 1 min.

    Strangely we are now getting an error when marking a record inactive that the "Creation Date" is in the future.

    I'll check the timezone of the client, and set it via the ServiceAPI to see if it makes a difference.

Children
  • Hi,

    Can anyone give me an example of how to set the WebClient timezone using the .NET wrapper for the ServiceAPI

    Our problem seems to be that some users the Timezone offset is set to -12 Hours even though the client machine is in the same timezone, but doesn't affect all users.

    Thanks.

  • Verified Answer

    You can allow the user to select their time zone and set it in the web client user options using ApplicationSettings and WebClientUserOptions.

    So use the string array 'ApplicationSettings.Timezones to present a list of available time zones and then update the user options using trimClient.Post()

    var settings =  trimClient.Get<ApplicationSettingsResponse>(new ApplicationSettings());
    
    //timezones are in settings.Timezones
    
    
    UserOptionsResponse response = trimClient.Post<UserOptionsResponse>(
    new WebClientUserOptions() { Timezone = "???????" });