I am using quickfix .net engine.
StartTime=17:40:00
EndTime=17:25:00
I am running this on a New York server and clock on desktop shows NY local time.
However, the FIX session starts and ends at UTC time. My understanding of fix config was that the times were always Local.
Why might this be happening?
You might need to read the config section properly, once more.
StartTime, EndTime - time in the format of HH:MM:SS, time is represented in UTC
To use local time in the FIX config, you need to set in the config
UseLocalTime=Y
It is N by default. But an important point
Times in messages will still be set to UTC as this is required by the FIX specifications.
Related
Some events don't take place at any specific time and instead are meant to be valid for the whole day irrespective of the time zone the user is at.
For the sake of argument, let's say a system sitting on a server (up in the cloud) runs a job at 5 am and imports data from a different system between this run and the last (24 hours ago). The actual user sitting at his desk doesn't know when the job runs, the user only knows that they go to sleep at night, the server crunches all the entries for the day.
The next morning the user wants to see all the entries from yesterday (what ever the job produced) and they go to the app, pull up a calendar input selector and they pick the 5/26/2022 (today being 5/27/2022).
Assuming the developers followed best practices, the client will transform the date into it's UTC version and send it up through an API. Chances are, depending on where the user is located and the server is, there might be a mismatch.
I could send the date up without it being UTC or I could send a UTC date and try to adjust it back to local time so that I could then compare with the date on record (that exists without an actual time zone).
What I am asking is:
What's the more conventional answer to this particular problem?
Is the idea of a date without time or time zone just ridiculous?
Use UNIX Time. It will give you a timestamp that is universal no matter what timezone the user is in. You can then convert it into whatever timezone you want to.
The concern you describe is well solved/addressed by the ISO 8601 dates/time presentation protocol.
All modern software can read/write dates in ISO 8601.
In Unix machines, the correct command is date with option -I
-I[FMT], --iso-8601[=FMT]
output date/time in ISO 8601 format. FMT='date' for date
only (the default), 'hours', 'minutes', 'seconds', or 'ns'
for date and time to the indicated precision. Example:
2006-08-14T02:34:56-06:00
How can I write a native FileMaker 11 script that returns the UTC time and saves this in a field or a variable? I would like to avoid plugins and AppleScript. A negative answer would also be helpful.
I would like to have functionality similar to this AppleScript:
set UTCTime to do shell script "date -u"
display dialog UTCTime
Output:
Thu Jun 16 07:10:42 UTC 2016
The following script step would work but was first introduced in FileMaker 11.
http://www.filemaker.com/help/13/fmp/en/html/func_ref2.32.27.html
Get ( CurrentTimeUTCMilliseconds )
Returns:
63568967107528
I've also researched methods for determining the local time zone, but these also depend on having the UTC time first.
It is not possible to get UTC time natively in FileMaker Pro 11. The only times it get can is the local client time or the host time. Both are "wall clock" times - with no indication of the offset from UTC.
If you don't want to use a plugin or OS-level script, then I believe your only resource would be using a web-viewer - either by getting the UTC from an external service (provided your system is on-line), or by having it run JavaScript locally.
Note, however, that getting the result of JavaScript run in a web viewer back into FileMaker is far from trivial (see, for example, http://fmforums.com/topic/58535-scraping-data-from-a-javascript-variable/?do=findComment&comment=277317) and, in my experience, rather flimsy. If you really need this, I would recommend you do use a plugin or an OS script.
I am facing an issue with setting time on page properties on cq:Page. The time being set into the JCR is getting converted to the timezone that is set in author’s machine. For example: time being set when author is in India is saved as +5:30 while in NY it is being set with -4:00 offset. Is there any way this can be fixed ?
Thanks !
I don't think you want to change this, unless I misunderstood the issue. Time is linear, so at any given point in time, there are as many possible ways to express the time as there are valid time zones. Anyone who views that page information through the application (not directly viewing the JCR) should see that timestamp converted to their local system time.
QuickFIX has a configuration file where you set StartTime and EndTime. Unfortunately AFAIK QuickFIX only supports UTC for this configuration, whereas exchanges are often timezone dependent. This means that you need to remember to update this configuration file every time the clock changes.
Is there a way to set the StartTime \ EndTime parameters programatically instead of through the configuration file? That way you could adjust the timeset the correct values programatically.
There is a way to set this. You can can set a timezone as follows:
TimeZone=America/New_York
see the configuration guide.
It is weird that it is not in the quickfix configuration guide and it is present in the quickfixJ guide.
in our production environment we use always UTC times.
In the QuickFIX config file add for every counterparty the following line:
UseLocalTime=N
Please read the documentation here:
http://www.quickfixengine.org/quickfix/doc/html/configuration.html#Session
as per quickfix docs you should add
set UseLocalTime=Y
Indicates StartTime and EndTime are expressed in localtime instead of
UTC. Times in messages will still be set to UTC as this is required by
the FIX specifications.
We had an error
System.ArgumentException: Only UTC time is supported
Parameter name: oldtime
at QuickFix.SessionSchedule.IsNewSession(DateTime oldtime_utc, DateTime testtime_utc)
at QuickFix.Session.get_IsNewSession()
and the only way to fix it was to delete the store directory. Presumably the session timestamp like this
I'm developing an international software that act as a simple project management software and I'm facing a problem. This problem is about date/hour and time zone.
When a message is sent from one time zone to another time zone I can store the UTC (GMT) time in my database and then have it displayed differently according to the user's time zone. But this can't be done when I only work with date.
If I say a task is due to the 21st of March. Should I consider that this date can be 20 or 22 in some other countries ? What are your advices on this problem ?
Let's say a user in New York sets a due date for a project as "anytime on Monday 26 January". That means "anytime from 0600 Monday 26 January to 0600 Tuesday 27 January" in Brussels and "anytime from 2000 Sunday 25 January to 2000 Monday 26 January" in L.A.
So completing the task at 2100 on Monday 26 is fine in Brussels and N.Y., but too late in L.A.
One possible work around is never just work with the date. If the time is not specified, either set it for 0000 hrs or 2400 hrs on the date specified in the timezone of the user.
The users may have to deal with strange due dates/times, but speaking as someone who used to work internationally, it kinda goes with the territory.
You won't be able to achieve what you are trying to do without storing the exact time. You simply don't have enough information.
When you don't have a time, assume that the time is the end of business in the main locale for the application, then translate that time as you would any other time. An alternative would be assuming end of the business day in local time and adjust that to UTC. Everyone using the application would need to understand whatever default time assumption you make when the time is not specified. Coordinating to the main office may be best in a large enterprise whereas coordinating to local time may be best in highly decentralized environments where the local context is equally important.
If you aren't storing the minutes and seconds you have to assume that the date being entered is the desired date and not to any adjustments for GMT. Just put it in the database as is. The people on the west coast will have to assume that the due date is the same regardless of where you are in the world. If you want to adjust for time zones, you'll have to collect more information, like hour, minutes, and seconds.
The easiest solution would be just to display as the same date for everyone. The deadline would then effectively be midnight in the latest timezone.
Otherwise, decide what the default time of the deadline should be in the timezone the task was created in, e.g. 21st March 17:00 EST or 22nd March 00:00 EST and display that in the local timezone. The timezone difference will then push it into the previous day or next day accordingly for the viewer.
SQL 2008 allows for a Date datatype that does not have any time value associated with it. That allows someone to say I need this done by this Date, but I don't care if it is +/- several hours. If the date selected is 1/1/2009 but it happens on 1/2/2009 at 2AM their time, they probably don't care.
When the user needs something done by a specific date and time, like close of business on 1/1/2009 then you need to store it in a DateTime as UTC and convert it to local time client-side.
This will take much of the complexity out of indicating when something is completed, it'll either be completed near a specific day or by a specific time.
If you have a single instance of a DB, I would store all dates in the datetime timestamp of your DB server. If you are timestamping rows, consider GetDate() in T-SQL or as default value of the timestamped date column. Then you have your single reference point for all times. Consider UTC format there.
Then, all clients accessing the date do their own conversion into "local time" , which can be interpreted by things like : user preferences, date time stamp on client computer, etc.
Without knowing more, it hard to say exactly what the resolution is.
Your solution depends on your application and requirements.
I'd first store UTC + offset in your data structures, so it's easy to display for any timezone.
Most likely if a task or meeting is due at 12pm on 21/March in London then it will occur at 2130 on 21/March in Adelaide (+0930), but that is an application requirement not any sinister timezone related standard.
If you want the ultimate in flexibility, add a flag that can make the even due simultaneously in every timezone or at the same time no matter where you are (staggered) and show the event accordingly.
You might want to store the date in a from that is timezone aware. This will help you in your calculations. SQL Server 2008 for instance supports a datetimeoffset that does precisely this. Alternatively if you're using SQL 2005 with a bit of effort you can write your own SQL CLR data type to support this.