Assigning a string value to a datetime property reduces the date by one day.
Hi All,
When i'm assigning a string to a date time property eg) "20160330" to a datetime type property, the result is one day is reduced in the datetime property. Result) "20160329T230000.000 GMT".
But when it is assigned to a Date type property, returning the exact result.
Could any of you advise me on this behavior.
I'm working on PRPC 6.3
Thanks in advance for all your responses.
Thanks,
ArulDevan
Pegasystems Inc.
US
What timezone is your database and app server in? When you do not include a time I expect the default of 0.000 is used and then that time is converted to GMT you end up the day before. If it is a datetime property then why would you not be including a time when setting the property?
Virtusa
IN
Thanks Celeste for the response.
The App server and database server are in same time zone and the operator is configured to the same. (Europe / London).
I'm getting the expected when assigning to a date type property, but not to a datetime property.
Thanks,
ArulDevan
Accepted Solution
Pegasystems Inc.
GB
This post may also give more information about differences between the Date and DateTime types https://mesh.pega.com/message/219079
(See the PRPC Help as well).
As Celeste points out : If a DateTime object has its Time Component set to midnight (00:00:00) the date component will 'wander' across this boundary when calculating the same Date across different timezones.
Virtusa
IN
Thanks for the response.
Dose it meant that the time zone in the operator profile place a role in transforming the date?
Pegasystems Inc.
US
London is GMT + 1.
Thus 0.00 London time is 23:00 GMT the day before.
Updated: 6 Apr 2016 8:49 EDT
Pegasystems Inc.
GB
The Operator Time Zone *probably* is being taken into account here (depending on what you are doing: is the DateTime being entered in from a UI, which is displaying in the Operators Local settings ?)
Does the property need to be a DateTime - would using a PRPC Date ? ('just a date', however (and forever, and from wherever) you look at it).
Also:
London is GMT + 1.
Absolutely correct: but just to emphasize that this only true during British Summer Time (ie, 'Daylight Savings') ! (In Winter, London is GMT)
https://www.gov.uk/when-do-the-clocks-change
And finally (and this I'm a little uncertain of the connotations of this): there appears to be two ways (in general, across different systems/programming languages : not something specific to PRPC) to specify a 'timezone'.
There is the 'geographic' * type ; eg 'Europe/London' and there is the type which specifies a particular timezone for instance 'GMT +1'.
Because most places implement somesort of DayLight Savings; I would say (guess) that a system interpretting a DateTime String which has a 'geographic' type in it; will take any Daylight Savings Adjustments into account.
The Operator Time Zone *probably* is being taken into account here (depending on what you are doing: is the DateTime being entered in from a UI, which is displaying in the Operators Local settings ?)
Does the property need to be a DateTime - would using a PRPC Date ? ('just a date', however (and forever, and from wherever) you look at it).
Also:
London is GMT + 1.
Absolutely correct: but just to emphasize that this only true during British Summer Time (ie, 'Daylight Savings') ! (In Winter, London is GMT)
https://www.gov.uk/when-do-the-clocks-change
And finally (and this I'm a little uncertain of the connotations of this): there appears to be two ways (in general, across different systems/programming languages : not something specific to PRPC) to specify a 'timezone'.
There is the 'geographic' * type ; eg 'Europe/London' and there is the type which specifies a particular timezone for instance 'GMT +1'.
Because most places implement somesort of DayLight Savings; I would say (guess) that a system interpretting a DateTime String which has a 'geographic' type in it; will take any Daylight Savings Adjustments into account.
But if a DateTime String contains a specific zone (say 'GMT') - I would say (guess) that it probably won't (and probably shouldn't?) take any Daylight Savings adjustments into account.
(* I made this term up: it's the best I could come up with; but there is possibly a better way of describing this - dunno)