Identify the Time Zone if Possible [VD19]

Time zone bugs can be notorious and cause major problems - you don’t want a customer to receive their report 4 hours late, do you? To help prevent these kinds of problems, make sure to include time zones in date/time variable names.

Terms useful for common scenarios include:

• utc - Indicates only UTC is expected.

• local - Indicates only the “local” time zone of a given system/user is expected.

When using conventions like this, code like user_login_utc_date_time = current_local_date_time looks obviously wrong. And if a date/time data structure includes embedded time zone information, examining that in a debugger and comparing with variable names can be a quick way to discern correctness (or not).

The following examples show these distinctions:

There are a few additional considerations regarding time zones:

• Leverage data types that handle time zone information themselves: Some programming environments may support date/time data types that handle time zone information for you. If you have access to such a data type, use it. If time zone expectations are important in your code though, it can still be useful to identify the time zone directly in variable names.

• Leverage documentation to fill in gaps for variables that could have varying time zones: Sometimes you might have code that could work with dates/times in many (or all) time zones. That’s fine, and it can be impractical to specify all of that time zone information in the variable name itself. Make sure to document such expectations that cannot be clearly identified directly in the variable name.