Answers

The suggestion is to use the GETUTCDATE() function instead of the CURRENT_TIMESTAMP value. As the linked article explains, the datetime that GETUTCDATE() returns is always expressed with UTC as timezone. In other words, it is consistent regardless of any
local timezone setting.

Of course you'd have to correct its value to represent the desired timezone. That is, you have to correct it for the timezone that is used in all OrderDates.

I don't know what Central Time Zone is, but let's say that that is UTC - 6 hours, then you'd have to use DATEADD(hour, -6, GETUTCDATE()) to get the same time as CURRENT_TIMESTAMP on your central server.

Basically the CURRENT_TIMESTAMP returns the sql server instance datetime not your local date, I hope it might be the fu_curdate() might be utilising the localtimestamp of your machine, It you know what is return from that function , you can always use DATEADD
to shift time between your local system and sql server.

The suggestion is to use the GETUTCDATE() function instead of the CURRENT_TIMESTAMP value. As the linked article explains, the datetime that GETUTCDATE() returns is always expressed with UTC as timezone. In other words, it is consistent regardless of any
local timezone setting.

Of course you'd have to correct its value to represent the desired timezone. That is, you have to correct it for the timezone that is used in all OrderDates.

I don't know what Central Time Zone is, but let's say that that is UTC - 6 hours, then you'd have to use DATEADD(hour, -6, GETUTCDATE()) to get the same time as CURRENT_TIMESTAMP on your central server.

Well, you have to make some serious decisions. The big decision is whether or not to store the orders in the same time zone as the server's time zone. Normally, that would be the case. In your situation, it is currently not (yet?) the case. When they are
not the same, then CURRENT_TIMESTAMP needs correction when executed on the server.

GETUTCDATE() needs correction too, but that correction is the same wherever you execute the query.

So yes, that would be the equivalent of your mySQL trick, but it makes a big difference whether you substitute "NOW()" with CURRENT_TIMESTAMP or GETUTCDATE().

When I have worked with distributed systems, the best way is to put every machine on UTC. The ANSI/ISO Standards have a TIMEZONE clause on temporal columns that are implemented in DB2, Oracle and other SQLs. Microsoft is behind
the curve as usual. You will have to create tables for the local DST rules, etc. and use them in VIEWs unless you can move this to the presentation layers where it belong.

The problem with telling app developers that they need to show UTC as local lawful time (this is not the same as local time!!) in their code is that app developers are dumb. Sorry, but it is true.

Well, you have to make some serious decisions. The big decision is whether or not to store the orders in the same time zone as the server's time zone. Normally, that would be the case. In your situation, it is currently not (yet?) the case. When they are
not the same, then CURRENT_TIMESTAMP needs correction when executed on the server.

GETUTCDATE() needs correction too, but that correction is the same wherever you execute the query.

So yes, that would be the equivalent of your mySQL trick, but it makes a big difference whether you substitute "NOW()" with CURRENT_TIMESTAMP or GETUTCDATE().

When I have worked with distributed systems, the best way is to put every machine on UTC. The ANSI/ISO Standards have a TIMEZONE clause on temporal columns that are implemented in DB2, Oracle and other SQLs. Microsoft is behind
the curve as usual. You will have to create tables for the local DST rules, etc. and use them in VIEWs unless you can move this to the presentation layers where it belong.

The problem with telling app developers that they need to show UTC as local lawful time (this is not the same as local time!!) in their code is that app developers are dumb. Sorry, but it is true.