Ms Access documentation suggests there is a data type called "Date/Time Extended" which:
The Date/Time Extended data type stores date and time information and is similar to the Date/Time data type, but it provides a larger date range, a higher fractional precision, and compatibility with the SQL Server datetime2 date type.
However I cannot select this as the option is not in the table design Data Type drop/down list.
My version is Microsoft Access for Microsoft 365 (16.0.12827.20328) 64-Bit.
How can I use the "Date/Time Extended" data type?
As far as I can tell, Date/Time Extended is not yet available in the latest release builds.
The documentation seems to be ahead of the actual release.
If you need it regardless, go to the Account page, and sign up for Office Insider, the beta channel, then click update options, and Update Now.
After that, it's in the dropdown for field types. Note that using it will break compatibility with previous versions of Office.
I can currently use the Date/Time Extended data type, and am on version 16.0.13012.20000 (latest beta channel).
Note that I strongly recommend on refraining from using this type for other purposes than testing until it's in a release version and you're 100% sure everyone using the database you intend to use it in has updated to a version that allows it.
Seems it was released in May see Office Insider Monthly (Targeted) v2005 build 12827.20210 - May 21.
But you have to enable it in Options first.
As of today it should be availible on all channels except Semi-Annual Enterprise Channel.
To get your general release number (starts with 200X), check Word for Office Version.
Related
I am currently working on a Ingestion API Schema File for Salesforce CDP. Using postman, I was trying to format the data type fields in my payloads using various specifications:
yyyy-mm-dd'T'hh:mm:ss'Z
yyyy-mm-ddThh:mm:ss.SSSZ
yyyy-mm-ddThh:mm:ssZ
and so forth. According to Salesforce's documentation, the payload data type field should be in ISO 8601 UTC Zulu with format yyyy-MM-dd'T'HH:mm:ss.SSS'Z (which does not work as the field value returns empty when ingested, although the call response is 'true'), however, talking to Salesforce support, they have suggested I try the following format:
2019-11-06T06:24:42.558008Z
With this, I finally managed to insert a record with correctly populated date fields into the CDP data object. However, I have never seen this format before and I am not sure how to work with this - I couldn't find any documentation on it that I can use to better understand it. Salesforce support was also not able to provide more explanation than "this is the format that works".
Any help or resource would be greatly appreciated.
(Also, did anyone else ever have this type of issue with Salesforce CDP? The platform is quite new with many bugs and the fact that it only accepts the above format seems a little strange to me...)
It's an RFC 3339 date, a "profile" of ISO 8601.
The RFC does not specify the number of decimal places for the fractional seconds. However, there is precedent in, for example, the Python standard library for using six-digit microseconds:
datetime.isoformat(sep='T', timespec='auto')
Return a string representing the date and time in ISO 8601 format:
YYYY-MM-DDTHH:MM:SS.ffffff, if microsecond is not 0
Different Salesforce APIs have different datetime-formatting requirements and can be quite strict about them. (And not all conform to the RFC). For example, the Bulk API does not work correctly with six-digit microseconds. There's little you can do besides conforming your data to the specific expectations of the API you're using.
I need inputs on how to do this process.
Take in Word/Excel/PPT documents. These documents will be regularly updated and changed for company's internal use.
Display them on a webpage.
Initial Discussions are to convert OfficeFormats to JPEGs/PDFs for Display.
What would be a recommended solution (need a program/not something like Office 365 or Google Docs)?
PS: The team is good at ASP.NET and using APIs.
I am currently creating application which requires Current Time From the Country.
I have latitude and longitude of different Country.
I have use following Link to get the Current Time
http://api.geonames.org/timezone?lat=21.7679&lng=78.8718&username=demo
(demo user name is by default and used only for testing because it has query limit)
I got the current Time but when Daylight Saving Time is ON. Is that API gives me the correct Time? If not then how could i get the current Time.
In some of the API I get the current time like earthtool(not implemented DST). But i could not Test because currently there is no DST Implemented so how can i test in this case?
I am Creating Application in .NET with C# 4.0
If any other API then please Tell Me but first priority to GeoNames API.
I would be very surprised if that didn't reflect the current local time. The results for Sao Paolo (which is currently observing DST) seem to agree with that:
<geonames>
<timezone tzversion="tzdata2012f">
<countryCode>BR</countryCode>
<countryName>Brazil</countryName>
<lat>-23.0</lat>
<lng>-46.0</lng>
<timezoneId>America/Sao_Paulo</timezoneId>
<dstOffset>-3.0</dstOffset>
<gmtOffset>-2.0</gmtOffset>
<rawOffset>-3.0</rawOffset>
<time>2012-12-17 10:48</time>
<sunrise>2012-12-17 06:14</sunrise>
<sunset>2012-12-17 19:47</sunset>
</timezone>
</geonames>
However, another alternative would be to use the GeoNames API to get the time zone ID, and then use Noda Time for everything to do with that time zone. (Disclaimer: I'm the primary developer of Noda Time.)
You can't just use the BCL's TimeZoneInfo class directly, as that doesn't support TZDB the time zone IDs that GeoNames provides (e.g. "Asia/Kolkata"). You could just use a mapping (CLDR provides one) but in my experience the Windows time zone information has some disturbing oddities.
If you just need to know the current time, GeoNames is probably fine -
GWT doesn't serialize Java Date properly. When I tried sending Date created in Javascript through the wire, I found out that dates between April 1st (funny) and 25th October for years before year 1983 get subtracted by one day.
That means that, say, both 1982-04-01 and 1982-03-31 become 1982-03-31 on the Java side.
Given the dates in question, I would guess that this is some kind of DST problem. I've tried googling, and found only one other reference that describes similar problem.
I also tried submitting bug to the GWT team, but curiously wasn't able to find bugtracker for GWT.
So, my questions are:
Anyone else run into this? I'm on GWT 1.7, and would like to confirm if this happens on 2.0 as well.
My workaround was to send dates as Strings, and parse them on server. Anyone knows better workaround?
Assuming that you are using a java.util.Date
Question 1: It seems that it is fixed in 2.0. I've created both Dates above (1982-04-01 and 1982-03-31) and they come through correctly to the server (both represent on the server as 1982-04-01 and 1982-03-31 respectively). My setup is:
GWT 2.0
Java 1.6
OSX 10.6.2
Question 2: You could always pass the 'milliseconds since January 1, 1970, 00:00:00 GMT' over the async service-which you can get using getTime() on the date object. On the server side you can then instantiate a new Date passing this value in on the constructor:
Date date = new Date(millis);
This saves fiddling around with formatters and parsers.
Dates and times are a complicated subject. The conversion can depend on the locale that the browser is running in and wether both you JVM on the server and the locales of the clients are up-to-date.
In some cases there can be differences because in some regions they switched timezones in the past.
GWT sends dates using just millis since epoch time. Since it is using Date objects, you are limited in that the Dates on the server side will be automatically modified to the servers timezone. Are you sure that you take into account the possible difference in timezones between client and server ?
David
I'm pretty certain the FTR library has some date emulation in it.
http://code.google.com/p/ftr-gwt-library
If you don't have to do client-side conversions (adapt to user's timezone) or calculations send it in a String from the server.
Never came across your specific problem though.
The possible problems soure is difference in Client/Server time zones.
We have also run into a similar problem. It was long enough ago that I do not remember the exact details but the gist of it was there were some minor differences between java.util.Date and the way dates were handled in Javascript. Our workaround was effectively the same as yours, where the actual value sent over the wire was generally a String.
I want to implement timezone in my web application. I researched and saw most web app use a GMT dropdown, here is the link to that dropdown http://www.attackwork.com/BlogEntry/6/Time-Zone-Dropdown-Select-List/Default.aspx
Then I saw this article suggesting UTC is the way to go when it comes to implement timezone. https://web.archive.org/web/20210513223048/http://aspnet.4guysfromrolla.com/articles/081507-1.aspx Basically it's saying don't use DateTime.Now instead use DateTime.UtcNow
My questions are,
Is there a dropdown of the timezones in UTC, like the first link I showed there is one on GMT?
Should I really use UTC or GMT?
.NET 3.5 provides the TimeZoneInfo class which should make it relatively simple for you to populate a dropdown with time zones. GMT came before UTC and UTC was officially instituted on January 1, 1972. See this link for more information. For today's purposes, the two are pretty much synonymous, though they have different historical origins. Use whichever looks and functions better for your purposes.
I'm not sure if this is what you intended to ask, but in your database you should always store timestamps in UTC/GMT (as noted by others they mean essentially the same thing). For each user of your web app, store the time zone preference.
Then whenever you display the timestamp for something to a user, convert the UTC time in the database to the user's timezone.
GMT (Greenwich Mean Time) is the same as UTC (Universal Coordinated Time). This isn't an either/or choice - use it :)
Use Localization settings, functions and features anywhere possible.
If you aren't running against SQL Server 2008 or don't want to abstract timezone management to the database, you should store all times as UTC/GMT and apply the timezone difference based off the user's profile setting, so that users from all around the world can see timestamps on events in their local time.
The distinction between UTC and GMT is probably too fine to bother with in your code. However, it's probably a good idea to always save and process times internally with zero timezone offset, and deal with it as a presentation concern.
It's also possible to use JavaScript to determine the user's probable timezone: examine the timezone offsets for some pair of Date objects reasonably close to the solstices (even January 1 and July 1 makes a suitable approximation) to obtain a coarse timezone identification. Feel free to use this information to determine a default timezone, but do allow it to be changed by the user: JavaScript doesn't provide sufficient detail to select the exact timezone with national and regional historical shifts, and it may not be enabled by the user anyway.