I have a Lotus Domino server sitting in CET/CEDT.
An email on that server has a DeliveredDate, maybe in the same time zone, maybe not, but let's have it set to 2014-03-01 11:01:38 CET.
Second thing I have is some "canonical time zone string" of another timezone, let's say Z=-4$DO=0$...$ZN=Arabian
How can I get - in a LotusScript ServerTask - the DeliveredDate converted to the time zone represented by aforementioned time zone string?
If some LotusScript servertask puts that date into a NotesDateTime object, I can get the properties LSLocalTime, which is CET, LSGMTTime, which is GMT, and ZoneTime, which of course also returns CET. Functions include ConvertToZone, which does not take a string, and the undocumented merge, which changes the time, such that 11:01 CET becomes 11:01 AST (8:01 CET).
But a delivered date of 2014-03-01 11:01 CET should become 2014-03-01 14:01 AST;
and a delivered date of 2014-04-01 11:01 CEDT should become 2014-04-01 13:01 AST.
How?
Notes formula language has a function that does exactly what you want. It's called #TimeToTextInZone. According to this developerWorks thread, there is no equivalent in LotusScript. However, you could try using NotesSession.Evaluate() combined with #TimeToTextInZone.
It looks like that string contains the values for the zone and dst arguments to ConvertToZone, so you can just parse it and use that method, right? Am I missing something?
Related
So I need to check whether the current time is after a EndDate, which is a date stored as 19:00 UTC. I only need to know if it's the next day.
This is what I'm currently doing
const now = moment();
const tooLate = now.isAfter(moment(EndDate), 'day');
I worry about timezones. I supposedly need this for central time. Is this sufficient? Or do I need to worry about the timezone? As I understand it, moment runs in UTC to start with.
Depends on the format of EndDate. By default moment() will parse in local time, so unless EndDate is a JS Date object, a unix timestamp (e.g. 1318781876406), or in string form with UTC offset (e.g. 2013-02-08 09:30:26.123+07:00) then you will have a problem if it is not in the same timezone as the client.
You can use moment.UTC() to parse in UTC time instead of local time. This should be enough to solve the any formatting problems you might have with EndDate
In the teradata documentation it says:
"Suppose an installation is in the PST time zone and it is New Years Eve, 1998-12-31 20:30 local time.
The system TIMESTAMP WITH TIME ZONE for the indicated time is ' 1999-01-01 04:30-08:00 ' internally."
This does not mesh with my understanding. I figure it ought to be '1999-01-01 04:30+00:00' internally because it should be stored in UTC.
Or, it can be stored as a the local time with a -8 offset, but this example seems to mix the two. Perhaps I am misunderstanding the text?
Not sure if this is an answer, but it's too long for a comment.
That "internal" storage part is very misleading. We don't care how Teradata stores anything internally.
I find this easier to look at using BTEQ, since SQL Assistant doesn't show timezones, at least by default. So, assuming you've logged into BTEQ...
--set session timezone to pst (GMT - 8)
SET TIME ZONE INTERVAL -'08:00' HOUR TO MINUTE ;
create volatile table vt_foo (
ts_w_zone timestamp(0) with time zone,
ts_wo_zone timestamp) on commit preserve rows;
insert into vt_foo
select
cast('1998-12-31 20:30:00' as timestamp(0)),
cast('1998-12-31 20:30:00' as timestamp);
select * from vt_foo;
Currently the two values (with and without tz) will match.
ts_w_zone ts_wo_zone
------------------------- --------------------------
1998-12-31 20:30:00-08:00 1998-12-31 20:30:00.000000
Now let's change the timezone for your session to something else, and look at what we get.
SET TIME ZONE INTERVAL -'03:00' HOUR TO MINUTE ;
select * from vt_foo;
ts_w_zone ts_wo_zone
------------------------- --------------------------
1998-12-31 20:30:00-08:00 1999-01-01 01:30:00.000000
The timestamp with zone is still the same. Displaying it without timezone is automatically converting it to your session timezone, which in this example is GMT -3.
EDIT:
Technically, Teradata is actually storing the time with timezone as GMT (1999-01-01 04:30:00) with the timezone offset (-8). That's where the documentation gets the 1999-01-01 04:30-08:00 value from). But that is not how it displays it.
I have a DateTime in my .NET program that I need to print with particular value of time zone offset (for instance, +01:00 always). Output should contain full date time with timezone. It has to be unrelated to system timezone setting. How I could achieve this?
Example: I have a timestamp such as 12-03-2016T12:30:34+03:00 and I need to output it calculated for predefined TZ +1: 12-03-2016T10:30:34+01:00
Found some approach to it.
First of all, DateTime does not have time zone stored in it. Instead it has flag whether it is UTC or Local (without the idea what Local TZ shift is). So: first thing is to get your initial parsing of time from any string time stamp in UTC.
Once it is stored in DateTime object (with Kind=UTC), you have to convert it to the timezone you desire output for. I find examples here useful: datetime to string with time zone.
Note: if you need to convert London daylight-saving time, you have to know right names of timezones in NET so you get it right. See Difference between UTC and GMT Standard Time in .NET
I'm confused about the DateTime field type in Web SQL (SQLite?).
Should I store my date/time values as a getTime() in milliseconds, or as a YYYY-MM-DD HH:MM:SS:SSS string?
And if storing in milliseconds, what field type should I use?
In general, I'd use the ISO 8601 format and a text column to hold them. SQLite doesn't have any native time types but its native date and time handling functions work with ISO 8601 formats:
All five date and time functions take a time string as an argument. The time string is followed by zero or more modifiers. The strftime() function also takes a format string as its first argument.
The date and time functions use a subset of IS0-8601 date and time formats. The date() function returns the date in this format: YYYY-MM-DD. The time() function returns the time as HH:MM:SS. The datetime() function returns "YYYY-MM-DD HH:MM:SS".
So if you're ever going to need to manipulate your timestamps inside the database (and you probably will sooner or later) then you'll want to use YYYY-MM-DD HH:MM:SS strings.
If you won't be manipulating your timestamps inside the database (beyond simple comparisons) then you can probably use a seconds-since-epoch integer without difficulty. Also note that sometimes you can use a seconds-since-epoch value natively:
The "unixepoch" modifier (11) only works if it immediately follows a timestring in the DDDDDDDDDD format. This modifier causes the DDDDDDDDDD to be interpreted not as a Julian day number as it normally would be, but as Unix Time - the number of seconds since 1970. If the "unixepoch" modifier does not follow a timestring of the form DDDDDDDDDD which expresses the number of seconds since 1970 or if other modifiers separate the "unixepoch" modifier from prior DDDDDDDDDD then the behavior is undefined. Due to precision limitations imposed by the implementations use of 64-bit integers, the "unixepoch" modifier only works for dates between 0000-01-01 00:00:00 and 5352-11-01 10:52:47 (unix times of -62167219200 through 10675199167).
so you can say:
SELECT datetime(1092941466, 'unixepoch');
and get '2004-08-19 18:51:06' back. Specifying the 'unixepoch' modifier is a bit cumbersome though and causes interesting things to happen when you inevitably forget it:
-- 1333482187 is 2012-04-03 19:43:07
sqlite> select strftime('%m', 1333482187, 'unixepoch');
04
sqlite> select strftime('%m', 1333482187);
43
As usual, the real answer is it depends but ISO 8601 strings are probably your best bet.
I know this question has been hashed over multiple times and I read lots of posts on that hashing but still am confused.
Using MVC4/WebAPI, I have a datetime that is simply created as new DateTime.Now.
My WebAPI is return data like this:
HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.OK, new
{
data = sessionRecordSmalls,
count = sessionRecordSmalls.Count,
success = true
});
where sessionRecordsSmall has a public property of DateTime in it.
When I look at the date in the VS debugger, it shows it as now with no timezone of course because DateTime does not include a timezone.
{10/6/2012 9:45:00 AM}
When I look at what gets downloaded from the server, I see in the JSON
2012-10-06T09:45:00
I think the T0 means Timezone 0, not 100% sure of that. My JavaScript library interprets it as timezone 0, then shows the actual date downloaded as GMT (-9 hours ago for me).
My question is, what is the JSON downloaded? Is that include a timezone? Am I missing some important step here?
if serializing with json.net keep in mind that you can specify DateTimeZoneHandling.
Example in WebApiConf.cs
var json = config.Formatters.JsonFormatter;
json.SerializerSettings.DateTimeZoneHandling =Newtonsoft.Json.DateTimeZoneHandling.Local;
The date time 2012-10-06T09:45:00, which we recive in JSON with Web API and default serializer is the ISO 8601 format.
In fact this is so called Combined date and time representations. Extract:
..A single point in time can be represented by concatenating a
complete date expression, the letter T as a delimiter, and a valid
time expression. For example "2007-04-05T14:30"...
There is no time zone information in this format. As mentioned in the Time zone designators Extract:
Time zones in ISO 8601 are represented as local time (with the
location unspecified), as UTC, or as an offset from UTC. If no UTC
relation information is given with a time representation, the time is
assumed to be in local time.
In other words, if there is no offset from UTC specified, it is treated as a local time.
The UTC format would be extended with Z at the end
If the time is in UTC, add a Z directly after the time without a
space. Z is the zone designator for the zero UTC offset. "09:30 UTC"
is therefore represented as "09:30Z" or "0930Z". "14:45:15 UTC" would
be "14:45:15Z" or "144515Z".
UTC time is also known as 'Zulu' time, since 'Zulu' is the NATO phonetic alphabet word for 'Z'.
So, the date-time we recieve is the ISO 8601 format, treated as local time zone (no Z at the end like this 2012-10-06T09:45:00Z)