D
dbeavon
Guest
Thanks for the tips Gus. I suppose it is possible that I have exaggerated the complaints about how confusing this API is. It doesn't sound like anyone else has the same trouble that we have. But I still think it would be nice to have some OO wrappers with semantics that are a bit more explicit and intuitive. The fact that some of the API will implicitly take into account your session (SESSION:TIMEZONE and SESSION
ISPLAY-TIMEZONE) can be both a good thing *and* a bad thing. The use of the session will introduce a bit of uncertainty into the API, since those are used "under the hood". I suspect that they are necessary for some complex reason, like preserving compatibility between the code that *is* and the code that is *not* aware of the existence of timezones.... But I must say that I really don't like them; these TIMEZONE-related session members act in a way that brings to mind "shared variables" (shudder). Some of our code is written in a way that is *not* bound to one individual timezone (eg. batch processes, services and such). This type of code may deal with transaction data from many timezones. The fact that this ABL batch-process-code is implicitly making use of it's *own* SESSION:TIMEZONE is problematic, especially if SESSION:TIMEZONE is not set to UTC. Thanks for the feedback.
Continue reading...
ISPLAY-TIMEZONE) can be both a good thing *and* a bad thing. The use of the session will introduce a bit of uncertainty into the API, since those are used "under the hood". I suspect that they are necessary for some complex reason, like preserving compatibility between the code that *is* and the code that is *not* aware of the existence of timezones.... But I must say that I really don't like them; these TIMEZONE-related session members act in a way that brings to mind "shared variables" (shudder). Some of our code is written in a way that is *not* bound to one individual timezone (eg. batch processes, services and such). This type of code may deal with transaction data from many timezones. The fact that this ABL batch-process-code is implicitly making use of it's *own* SESSION:TIMEZONE is problematic, especially if SESSION:TIMEZONE is not set to UTC. Thanks for the feedback.Continue reading...