Omniscope 2.8, available shortly, fixes a known issue with publishing IOK files with date fields to recipients in different regions.

2.7 and earlier

Dates in Omniscope are modelled as absolute points in time (known as "unix" or "epoch" time) and are displayed in the local time zone in whatever format is configured for the field - e.g. "month-year", stored as the instant at the beginning of the month in question.

Additionally, different regions have different "first day of week" settings, leading to different week number calculations.

Typically this can lead to dates appearing offset by a day, or week histograms starting on the wrong day of the week (Sunday vs. Monday), when an IOK file from 2.7 is opened on a PC in a different region.

Until your publishing and end-user installations have been updated to Omniscope 2.8, you will need to either author the IOK file in the recipient's time zone, or will need to store dates as hidden text fields with a TEXTTODATE formula field configured to recalculate on open.

2.8 and later

As with 2.7, dates continue to be modelled as absolute points in time. But now, IOK files carry the originator's timezone and calendar week settings with them.

Time zone handling

Omniscope 2.8 now captures a fixed time zone when you create a file, which is the system time zone at that point. It also captures the current time zone when you first save a legacy file (from 2.7 or earlier) using 2.8+, although that setting will be lost if you subsequently save in 2.7.

When a time zone-aware file (saved in 2.8+) is subsequently opened, it continues to work in the same originating time zone. It doesn't matter whether you view or edit it on another PC the other side of the world, the time zone is still fixed to the originating time zone.

All date fields are recorded internally, manipulated, and displayed, in that time zone. This means that you'll always see the same date calculations regardless of local system time zone.

Unfortunately this will have no effect for clients still using 2.7 or earlier until they upgrade to 2.8. See workarounds above, meanwhile.

Regional settings dialog

You can use Settings > Advanced file settings > Regional settings to:

• Review all regional settings and related.
  
• Change the calendar week settings according to the target audience, if needed.
  
• Change the setting and convert any date fields. Typically you wouldn't normally need to do this; the conversion isn't exhaustive. However, if your file has the wrong setting and has "hidden date offsets" due to being created in a "pre-June-2.8" version of Omniscope, you can correct it.
  
• Diagnose "hidden offsets" (symptoms of a legacy file with the wrong time zone setting).
  

Calendar week settings

In the same dialog, Omniscope also captures some calendar week settings. This is for a similar reason to time zone. Calendar week settings vary by locale (Saturday/Sunday/Monday as first-day-of-week), yet your formulas must be able to perform week-of-year settings without the local PC settings affecting the result.

As per time zone, these settings are captured and frozen when you create a file, according to the typical regional settings for your PC's locale. The dialog also explains what are normal settings for different locales.

Language and data locale

The pre-existing settings "Language" and "Data locale" still work as before. They are installation settings, which aren't saved as properties of a file. But they no longer have any impact on most date calculations / manipulations / storage. Previously they affected calculations in rare situations.

"Language" means the interface language, and has no effect on data manipulation or display.

"Data locale" means that (by default) if you're in France, you'll see comma for decimal point and French textual month/day names.

Please be aware that if you are using formulae to process numbers or dates inside text values, you should provide an explicit locale ID in the formula function arguments. Without this, textual month/day names, and decimal point / thousand separator characters, will follow the rules of the local installation's "data locale" setting.