Tagged with timestamps - Visokio Forums http://forums.visokio.com/discussions/tagged/timestamps/feed.rss Mon, 30 Oct 17 15:57:25 -0400 Tagged with timestamps - Visokio Forums en-CA Output: Timestamping output files? http://forums.visokio.com/discussion/2993/output-timestamping-output-filess Wed, 19 Aug 2015 11:04:01 -0400 kmccready1 2993@/discussions
I am relatively new to Omniscope and I am setting up a simple job which will take a file from a location, remove duplicate rows, and output the file back to the same location. I am having trouble finding a setting which will allow the file to have a datestamp (and thus apply the datestamp back to the transformed file), so that we can automate this process.

Is it possible to do this?

Thanks,
Kayleigh]]> Idea: Outputs - Time-stamping Published Data files? http://forums.visokio.com/discussion/2211/idea-outputs-time-stamping-published-data-filess Tue, 25 Jun 2013 07:34:11 -0400 naruemon 2211@/discussions
It would be good if we could add the Publish date/time in the title/header or in the bottom. Then the users who browse to the link can verify whether the report is up to date or not by themselves.
]]> Output: Add time stamp with today's date to file names? http://forums.visokio.com/discussion/2192/output-add-time-stamp-with-todays-date-to-file-namess Thu, 13 Jun 2013 08:55:37 -0400 davedunckley 2192@/discussions
Is there the ability to automatically save an imported data snapshot or timeslice files with today's date as a suffix?

So I could in the Scheduler, have it save each snapshot/timestamp as 'filename_ and it would save the output as 'Filename_130613.iok'?

Dave
]]> Date/Time: Day of week changing? http://forums.visokio.com/discussion/1898/datetime-day-of-week-changings Wed, 14 Nov 2012 12:27:08 -0500 ALC 1898@/discussions
Any suggestions on how I can fix this?

Thanks, Anna
]]> Date/Time: Cross-time zone publishing fix (2.8+) http://forums.visokio.com/discussion/1617/datetime-cross-time-zone-publishing-fix-2.8- Thu, 21 Jun 2012 11:53:40 -0400 steve 1617@/discussions

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.]]> Scheduler: Creating files with unique filenames http://forums.visokio.com/discussion/903/scheduler-creating-files-with-unique-filenames Tue, 02 Aug 2011 15:43:20 -0400 Mees 903@/discussions As we need a unique filename per file, we use the timestamp to include in the filename.

However, we are facing a problem we didnt expect..... The process runs so fast that some files are created in the same second. This means we loose the functionality of creating unique filenames.

To avoid this situation we need to slow down the scheduler process, of course something we do not want.
As a workaround we inlcude the File action 'Save iok' to win some time before the next file is generated.

We hope there is a better solution.
1 - have a least 1 or 2 seconds between file creation
2 - have another way to create a unique file name; ideal would be to use an ID field in the filename

Thanks
]]>