In each distribution of LogicBlox, there are two CSV files pertaining to supported time zones:
logicblox-4.x.x
|
└─share
|
└─logicblox
|
└─BlockResources
|
└─timezone
| date_time_zonespec_one_reg_per_tz_code.csv
| date_time_zonespec.csv
Which is the correct one to use when building applications which use time zones? Are valid time zones held in an internal predicate which we can print?
The main timezone specification file is date_time_zonespec.csv. This data is used with datetime-related built-ins, such as datetime:format, parse, create etc. There is currently no way in logic to obtain the list of valid regions or timezone codes.
The file one_reg_per_tz_code is only used to map a timezone code (for example EST) to a default region (for example America/New_York). The reason this file exists is that the lower-level datetime library that we use (boost) supports most timezone notations only as output, not input. The reason for this is that some common timezone notations are surprisingly not a unique indication of a set of timezone rules (e.g. AST/ADT does not have the same rules, and EST is used by Australia as well as the US). Unfortunately, in practice we do have to work with data that uses such timezone notations, so we use this csv file to map the timezone codes to one specific region that does indicate a unique set of timezone rules. This default mapping we picked might not be the desired one for your application though.
It is best to always work with region codes (like America/New_York) to avoid any confusion.
I expect that in the medium-term we will change our datetime and timezone handling to a different library. One reason is the poor parsing support in boost, but another reason is that we really want to use a timezone database with all historical timezone rules, not just the current ones (as specified by this spec file).
Related
Discussing data time-formats, someone mentioned to me how he stores datetime (in a human-readable format) using floats as yyyymmdd.hhmmss, so 2019-09-18, 11:29:30am would become 20190918.112930
I'm trying to find out if this guy has invented his own format or if it is used (and described) elsewhere too - and if so, how is it even called...?
It’s probably homespun
I have seen a lot of date and time formats, and I have not seen this one before. My go is that his guy or his organization invented it themselves.
Edit: Thank you for confirming in the comment. Since comments are not always permanent on Stack Overflow, I quote here, you said:
Finally got confirmation from the source: it's homespun indeed.
As an aside I don’t like it. A float is stored in a binary format internally, and only after formatting it into decimal does it become human readable. Using a float for a “human readable” date and time was not what formatting of floating-point numbers was meant for, it’s a hack.
Use ISO 8601
For a human-readable format I recommend ISO 8601. Here 2019-09-18, 11:29:30am becomes 2019-09-18T11:29:30. Or even better and still within ISO 8601, convert to UTC and append a Z to denote UTC. So if your original time was in Europe/Berlin time zone, it would become 2019-09-18T09:29:30Z. As you can see, ISO 8601 is even more human readable than you friend’s format, and it is sortable as strings (as long as the years don’t go beyond 9999).
While he may have come up with it himself, it is also a formatting option in zipinfo.
The manual doesn't explicitly name it, but describes it as a sortable decimal format and decimal format.
Not sure if we are talking about SQL date format. If so, this date format is present in SQL Statements.
Not sure about the name, it's called in different ways: non-standard, ISO, Other format and so on.
Is present also in PHP.
According to Wikipedia, this would be similar to the ISO 8601, which permits, all of the following for date and time combined:
2019-09-18T09:18:26+00:00
2019-09-18T09:18:26Z
20190918T091826Z
except that the T to separate the time from the date is replaced by . and the time-zone information is dropped.
That specific format has limited popularity either in the yyyymmdd.HHMMSS or the C's strftime()-compatible %Y%m%d.%H%M%S form.
EDIT
As far as using float for date and time the way you suggests, it depends on the precision and machine representation.
If the system is following IEEE 754 basic standard (which is what most modern C compiler stick to), you would need at least float64.
However, it is not common to do so.
This might be in part because it may be difficult to correctly predict the accuracy of the time information, and it is not as bit-efficient as the Unix time.
Given that the only positive feature it has is that it can rely on standard %f from sprintf(), I would only see it advantageous when strftime() is not available or a performance bottleneck.
I need to get to the time zone array using Chinese,but ,use TimeZone.knownTimeZoneIdentifiers get is English array
TimeZone.knownTimeZoneIdentifiers returns a list of IDs from the IANA TZ Database. A comprehensive list is available here.
These are not to be translated. They are identifiers, passed as parameters to code to identify a time zone. They are always in English, and their exact spelling, casing, and punctuation should remain intact. If you were to translate it, you would find they are not usable in any API.
If your goal is to display a human-readable translated string in a UI, then you should use the localized names provided by the Unicode CLDR project. I am not an iOS developer, so I can't be certain, but from reading the docs, I believe these are already available to you by using the localizedName instance method of the TimeZone class.
I have a node.js application that stores many dates in a database. They are stored in the ISO format, such as '2016-11-02T16:30:12-04:00'.
Some fields which are dates are just dates, other are date/times. An example of a date/time would be "last modified" for a record, where a person's birthday is just a date.
The question is about best practices for storage and query patterns on these things. Because a date always has a time, you must choose how to store for example a birthday. Following the 5 laws of API dates and times this is of course done in UTC.
There are edge cases though where proper API behavior seems unclear. Suppose someone submits a birthdate to the API of '2016-11-02T16:30:12-04:00'. This is bad news, because a search like /users?birthdate=2016-11-02 will fail, as that date will get converted to '2016-11-02T00:00:00Z' and fail to match in the DB. What then should correct behavior be?
When someone POSTs a user, convert date fields into dates at midnight UTC, and then have the convention that querying birthdates should assume the same?
Convert date queries for certain fields into implicit ranges, i.e. searching for 2016-11-02 is really looking for 2016-11-02T00:00:00Z <= x <= 2016-11-02:23:59:59Z?
Match only on the exact moment, and rely on the client to know that a birthday of '2016-11-02T16:30:12-04:00' really means 4:30PM EST, and does not mean just on November 2nd?
What's the established pattern / best practice here for distinguishing between dates and datetimes?
I have been studying REST best practices and standards a lot for a while and I can't recall reading anything about that, but for the usage of ISO standard. From your description it seems to be something that really depends on the application and its use-cases.
I would go for your option #2: if a GET request comes with a date but no time, consider it a query for the whole day, and do the "conversion" in your GET response server code. Maybe you'd want to support both a "date" and a separate "time" query string parameters if the precise time might matter occasionally. This can also help you to keep clients "unaware" of the database storage format you choose, and may even allow you to support localized date formats.
The problem here is the usage of UTC, which implies that there's a time associated with it. There's not, a birthdate is considered (in iCalendar) a 'floating date' and does not have a specific time associated with it.
If your birthdate is November 3rd, and you move to Australia, your birthdate does not actually change to November 2nd, because your birthdate does not have a time, does not have a timezone and is the same where ever you are in the world.
The solution is simple. If you allow users to submit a date/time for birthday searches, then you should just 'cut off' the time and timezone. Assume that you're only going to be using the date portion and just search your database based on that.
Ideally you don't allow users to submit a time at all though. I think this just creates confusion. Just force api clients to submit a date only.
Those '5 laws' are an extreme over-simplification and don't apply to many situations.
I have case classes that may be used for representing models that originate from either a database table or API object.
Should I use joda or java.util.date or java.sql.date or?
This is for a playframework app, and I will use these models to display the datetime on the UI side of things where I will convert the date to the current users timezone also.
I'm just really confused.
Agreeing with the Answer by mkurz…
java.time
Both java.util.Date and java.sql.Date, and their related classes, have been supplanted by the java.time framework built into Java 8 and later. See Oracle Tutorial. Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport and further adapted to Android in ThreeTenABP.
Search Stack Overflow to learn more (after reading the Oracle Tutorial linked above). Many examples and discussions have been posted.
Basic concepts
Date-time handling is surprisingly tricky. Leave your intuition at the door.
Strings are not date-time values; they are a representation of date-time values. Focus on using objects, not strings.
You may work with a date-only, a time-only, or a date-time.
Know that offset-from-UTC is just a number of hours/minutes/seconds while a time zone is a superset, adding rules for handling anomalies such as Daylight Saving Time (DST). Use OffsetDateTime for one, and ZonedDateTime for the other.
ISO 8601 standard provides sensible formats when parsing & generating Strings to represent date-time values.
The “Local…” types mean “no specific locality”. These have no meaning, are not points on the timeline, until you specify the context of a specific time zone.
The 3-4 letter abbreviations such as EST or IST you commonly see in the media are not time zones, are not standardized, and are not unique(!). Proper time zone names are continent/region.
Apply a time zone for presentation to the user, but most of your business logic, data storage, and data exchange should be in UTC (the Instant class).
Tips
While programming, forget about your own local time zone. Think in UTC.
Learn to read & write 24-hour clock times.
I would recommend http://www.joda.org/joda-time/quickstart.html
It works really nicely with play's json formatters and comes with a ton of helpers.
You are looking for java.time.ZonedDateTime which was introduced in Java 8 and should be used for representing date and time related information that have a timezone. You can save values like 2016-05-30T00:23:27.070Z with it. There is no need to use a third party library like joda time anymore (maybe in other cases there is, but not in your's)
(Do not use java.util.Date - most of it's methods are deprecated, for good reasons)
As a blogger saied:
「Scala does not have a datetime package, but we can use the ones provided by Java.
Java 8 provides a better data/time API, so 3rd-party libraries like Joda-Time is no longer required.」
Here is the blog:
https://www.hackingnote.com/en/scala/datetime
This will be helpful to you.
I've been searching for a definitive answer to this, and the XML schema data types document seems to suggest that timezones are accepted, yet I found at least one implementation which does not properly convert time zones ( NUSOAP ).
To make sure that the problem is not at my end, I'd like to know if a format such as 2009-11-05T11:53:22+02:00 is indeed valid and should be parsed with timezone information, i.e. as 2009-11-05T13:53:22.
Given the following sentences from the w3c schema documentation:
"Local" or untimezoned times are
presumed to be the time in the
timezone of some unspecified locality
as prescribed by the appropriate legal
authority;
and
When a timezone is added to a UTC
dateTime, the result is the date and
time "in that timezone".
it does not sound like there is a definitive answer to this. I would assume that it is the usual ambiguity: Both versions are principally valid, and the question of what version to use depends on the configuration/behavior/expectations of the system one is interfacing with.
And even if there where a definitive answer, I would definitely not rely on it, but rather expect that every other web service and library had its own way of dealing with this :/
You converted the timezone incorrectly.
2009-11-05T11:53:22+02:00
is equivalent to
2009-11-05T09:53:22Z
Is that what NUSOAP did?