How to automatically adjust datetimes to daylight saving time?

[Coooz]

Hi,

I need to find a way to adjust incoming datetimes in HL7 messages with regard to daylight saving time.

For example, I might know that the server time is one hour earlier than the time on client A that runs my channels on Mirth Connect. There is however also client B in a different country for which the server time is two hours later. I have made this configurable so that datetimes of client A always get one hour subtracted, and two hours are added to datetimes in client B.
But then because of daylight saving time I need to adjust all configurations. Suddenly on client A the local time is correct, and on client B the difference is three hours instead of two. In particular when calculating time spans this produces incorrect results.

How do I go about fixing this?

Thanks,

[pacmano1]

Not a mirth question. Time zone management is a pain in the rear. You gotta sort out the calculations for your use case(s).

However, I would normally not change timezones in the engine, rather call your db inserts/updates as per the timezone you know the client is in. Databases like postgres do that well.

[jonbartels]

A teammate recent handled a similar problem. Some key rules that we figured out during code reviews:

1. NEVER add and subtract hours, instead use real time zone conversions
2. Use time zones without DST - US/Pacific instead of PDT, US/Eastern instead of EST, and so on
3. Use java.time and never java.util.date and never DateUtils from Mirth

Roughly the process is:

1. Parse the time using java.time and set its zone to the input time
2. Use the java.time date time object and use the "atZone" conversion to shift to the target zone
3. Render the time using java.time again

[pacmano1]

@jonbartels actually suggested the harder way to do this if your downstream action is to insert data to databases. Database engines convert this stuff on the fly. Postgres is very good at it.

For example, assuming your client is in eastern time, the insert would be something like the below assuming you wanted to insert that eastern time as UTC.

-- Assuming you have a datetime in Eastern Time (whether EDT or EST)
INSERT INTO your_table (your_timestamp_column) 
VALUES ('YYYY-MM-DD HH:MI:SS'::timestamp AT TIME ZONE 'America/New_York' AT TIME ZONE 'UTC');

But do feel free to write mounds of code...

[jonbartels]

@pacmano1 is 100% correct if the source or target of your data is a database. The SQL he shows is for Postgres, other DB engines should have a similar capability.

Note that BOTH options use:

• real time zones with the geographic location
• the same tool/library is used to parse the time and shift the zone (eg dont parse with Java then insert with SQL; pick ONE and use it all the way through!)

[Coooz]

Thank you all for contributing. I don't need to target a database though, only to modify datetimes in HL7 messages. I'm sure I'll figure it out with what @jonbartels suggested in his first post.

[tonygermano]

I don't think other database engines are as good at this as postgres. It takes a little more code to script it using the java.time classes mentioned by @jonbartels mainly because you'll be calling multiple java classes, which can be a little verbose, but it is not that difficult and is way more powerful if you need extra functionality not provided by a db engine.

For example, one thing that I use it for is calculating the age of the patient at the date of service to place in a report header, and displaying it in months if < 2 years or years if >= 2 years (and it even easily handles edge cases involving leap years.)

This is what @pacmano1 's example would look like using java.time and hl7 timestamp formats.

var formatter = java.time.format.DateTimeFormatter.ofPattern('yyyyMMddHHmmss')
var converted = java.time.LocalDateTime.parse('20230912213456', formatter)
  .atZone(java.time.ZoneId.of('America/New_York'))
  .withZoneSameInstant(java.time.ZoneOffset.UTC)
  .format(formatter)
// converted = '20230913013456'

You can use different formatters for the initial parsing and the final formatting back to a string if you need to, e.g., if you are going from hl7 to a web request that expects dates in a different format.