Sparx Systems Forum
Enterprise Architect => Bugs and Issues => Topic started by: Mauricio Moya (Arquesoft) on March 19, 2022, 02:25:56 am
-
When you use Tagged Value Types and define one of them as "Date", the tag value displays a calendar when you click it so you can set a given date.
But, if, for example, your regional settings in windows are set as dd/mm/yyyy and you store a date as 04/03/2022 (march 4th) and another user in a different computer has a regional setting like mm/dd/2022, the calendar component assume the date as april 3rd.
Is there a way to deal with it, preserving the regional settings of the users?
-
Of course nobody at Sparx thought that would happen. I would not rely on any of those gimmicks. Store the date as string with a set convention as yyyy-mm-dd.
q.
-
Of course, nobody at Sparx thought that would happen. I would not rely on any of those gimmicks. Store the data as a string with a set convention as yyyy-mm-dd.
q.
Since ALL tagged values are stored as simple strings, there's NO way to avoid this problem. Since you don't know the timezone of the original entry, you can't convert on output. If you operate in multiple timezones, you may need to add the timezone to your string so that the date is accurate, in addition to q's format.
Paolo
-
I don't think you need a timezone unless you actually use time in terms of hours (and finer grained). Days are days and nobody cares about the overlap that happens on a few islands in a large ocean ;-)
q.
-
I don't think you need a timezone unless you actually use time in terms of hours (and finer-grained). Days are days and nobody cares about the overlap that happens on a few islands in a large ocean ;-)
q.
That is unfortunately not true, dates aren't always dates. A few of my assignments have involved worldwide time and date management. It's not always so simple.
Hopefully, in this case, it is, but various scenarios should be checked first. Living as we do at the eastern end of the world; it's much more apparent than for you guys who live in Europe close to "UTC central".
Paolo