11.05.2018 1:27, Adriano dos Santos Fernandes wrote:
On 10/05/2018 18:03, Vlad Khorsun via Firebird-devel wrote:
...
Could you answer my question below ?
Please, convert to UTC and explain how to do it:
2010.03.01 04:00 Europe/Moscow,
2013.03.01 04:00 Europe/Moscow,
2016.03.01
On 10/05/2018 19:27, Adriano dos Santos Fernandes wrote:
> Here I show interesting example when DST starts.
Correction: when DST *ends*.
Adriano
--
Check out the vibrant tech community on one of the world's most
On 10/05/2018 18:03, Vlad Khorsun via Firebird-devel wrote:
>
> To do it, you need to know TZ (or, offset from UTC) used at
> America/Sao_Paulo
> at given moment, isn't is ? And this offset is also depends on given moment
> itself. And in different moments there could be different offsets.
>
On 10/05/18 22:30, Leyne, Sean wrote:
No other database engine is maintaining various versions at the same
time.
Fortunately.
I believe that Oracle is.
I already put here link describing that when tz db is updated, times may
change if used in wrong version.
I think I misunderstood which
> >> No other database engine is maintaining various versions at the same
> time.
> >> Fortunately.
> >
> > I believe that Oracle is.
> >
>
> How?
>
> I already put here link describing that when tz db is updated, times may
> change if used in wrong version.
I think I misunderstood which
On 10/05/2018 18:22, Leyne, Sean wrote:
>
>
>> No other database engine is maintaining various versions at the same time.
>> Fortunately.
>
> I believe that Oracle is.
>
How?
I already put here link describing that when tz db is updated, times may
change if used in wrong version.
Adriano
> No other database engine is maintaining various versions at the same time.
> Fortunately.
I believe that Oracle is.
Sean
--
Check out the vibrant tech community on one of the world's most
engaging tech sites,
10.05.2018 22:08, Adriano dos Santos Fernandes wrote:
On 10/05/2018 15:30, Vlad Khorsun via Firebird-devel wrote:
The key is that DST doesn't affect given time zone. TZ could be
"standard time" based (such as MSK)
or "DST based" (such as MSD or IST you speak about) but TZ itself is
not
On 10/05/2018 15:30, Vlad Khorsun via Firebird-devel wrote:
>
> The key is that DST doesn't affect given time zone. TZ could be
> "standard time" based (such as MSK)
> or "DST based" (such as MSD or IST you speak about) but TZ itself is
> not changed with DST start\end.
> What is changed - is
On 10/05/2018 15:31, Lester Caine wrote:
> On 10/05/18 18:47, Adriano dos Santos Fernandes wrote:
>> 99.9% of our users will use the "official" database.
>
> And therefore will have no idea just which "official" database they
> are using. This is just carrying on the current mess that is inherent
On 10/05/18 19:30, Vlad Khorsun via Firebird-devel wrote:
The key is that DST doesn't affect given time zone. TZ could be
"standard time" based (such as MSK)
or "DST based" (such as MSD or IST you speak about) but TZ itself is not
changed with DST start\end.
What is changed - is what TZ
10.05.2018 21:21, Adriano dos Santos Fernandes wrote:
The name for Moskow is Europe/Moscow.
Please, convert to UTC and explain how to do it:
2010.03.01 04:00 Europe/Moscow,
2013.03.01 04:00 Europe/Moscow,
2016.03.01 04:00 Europe/Moscow
Regards,
Vlad
On 10/05/18 18:47, Adriano dos Santos Fernandes wrote:
99.9% of our users will use the "official" database.
And therefore will have no idea just which "official" database they are
using. This is just carrying on the current mess that is inherent when
one has no idea just which rules WERE
10.05.2018 21:13, Lester Caine wrote:
On 10/05/18 18:47, Vlad Khorsun via Firebird-devel wrote:
Regions that use Daylight Saving Time (DST) change the time zone name and time during the DST period. The words “daylight” or
“summer” are then usually included in the time zone name. The areas that
On 10/05/2018 14:47, Vlad Khorsun via Firebird-devel wrote:
>
> According to:
>
> https://www.timeanddate.com/time/time-zones.html
>
> ---
> Daylight Saving Time Zones
>
> Regions that use Daylight Saving Time (DST) change the time zone name
> and time during the DST period. The words
On 10/05/18 18:47, Vlad Khorsun via Firebird-devel wrote:
Regions that use Daylight Saving Time (DST) change the time zone name
and time during the DST period. The words “daylight” or “summer” are
then usually included in the time zone name. The areas that don't use
DST remain on standard time
On 10/05/2018 14:47, Dimitry Sibiryakov wrote:
> 10.05.2018 19:14, Adriano dos Santos Fernandes wrote:
>>> IMHO, one of advantages of using UDR for subj is that much more
>>> fields can be added any time as needed by upgrading a single library
>>> while a virtual table is fixed to ODS and has
10.05.2018 19:14, Adriano dos Santos Fernandes wrote:
IMHO, one of advantages of using UDR for subj is that much more
fields can be added any time as needed by upgrading a single library
while a virtual table is fixed to ODS and has to be decided once and
forever.
UDR needs metadata too, so
On 10/05/2018 13:32, Lester Caine wrote:
> This is exactly the problem, and using TZ data direct is the only
> reliable way to manage the CURRENT TZ rules. So as long as we can
> switch off ICU data then this may work, otherwise it is just another
> waste of time! In my case all the TZ material is
10.05.2018 20:29, Adriano dos Santos Fernandes пишет:
On 10/05/2018 14:23, Vlad Khorsun via Firebird-devel wrote:
Look how MSK time zone was changed at 2014.10.26
https://www.timeanddate.com/time/zone/russia/moscow
I think about something like this:
ID Name Valid from
On 10/05/18 17:24, Adriano dos Santos Fernandes wrote:
Would that name be the full name like Europe/Amsterdam, or would it
also include the imprecise (duplicates are possible) like CET?
Both, each one has a different ID.
There are multiple abbreviations that relate to different rules. Only
On 10/05/2018 14:29, Adriano dos Santos Fernandes wrote:
> In practical terms, it's the same as a DST change.
>
> A DST is nothing different than a "rule change" and another "rule
> change" every year.
>
>
Some time zones nomenclature are specific to the region's standard or
DST times, so they are
On 10/05/2018 14:23, Vlad Khorsun via Firebird-devel wrote:
>
>>> Look how MSK time zone was changed at 2014.10.26
>>>
>>> https://www.timeanddate.com/time/zone/russia/moscow
>>>
>>> I think about something like this:
>>>
>>> ID Name Valid from Offset
>>> ... MSK 2011.03.27
10.05.2018 19:57, Adriano dos Santos Fernandes пишет:
On 10/05/2018 13:47, Vlad Khorsun via Firebird-devel wrote:
10.05.2018 19:23, Adriano dos Santos Fernandes wrote:
On 10/05/2018 13:12, Vlad Khorsun via Firebird-devel wrote:
I guess the question is about the case when users have
On 10/05/2018 14:08, Dimitry Sibiryakov wrote:
> 10.05.2018 18:44, Vlad Khorsun via Firebird-devel wrote:
>> Is it possible\make sence to add a datetime field with "valid from"
>> mark ? Or something like that, some kind of version mark.
>
> IMHO, one of advantages of using UDR for subj is
10.05.2018 18:44, Vlad Khorsun via Firebird-devel wrote:
Is it possible\make sence to add a datetime field with "valid from"
mark ? Or something like that, some kind of version mark.
IMHO, one of advantages of using UDR for subj is that much more fields can be added any
time as needed by
10.05.2018 19:23, Adriano dos Santos Fernandes wrote:
On 10/05/2018 13:12, Vlad Khorsun via Firebird-devel wrote:
I guess the question is about the case when users have historical data
and need to apply old time zone rule to the old data and new timezone
rule
to the new data.
Is it
10.05.2018 19:02, Adriano dos Santos Fernandes wrote:
On 10/05/2018 12:53, Lester Caine wrote:
...
And how will the version of TZ data be handled! This is a key element
that has screwed normalized data in the past, and some way to manage
that normalized data needs to be included in the
> 10.05.2018 19:02, Adriano dos Santos Fernandes wrote:
> > On 10/05/2018 12:53, Lester Caine wrote:
> ...
> >> And how will the version of TZ data be handled! This is a key element
> >> that has screwed normalized data in the past, and some way to manage
> >> that normalized data needs to be
On 10/05/18 17:12, Vlad Khorsun via Firebird-devel wrote:
10.05.2018 19:02, Adriano dos Santos Fernandes wrote:
On 10/05/2018 12:53, Lester Caine wrote:
...
And how will the version of TZ data be handled! This is a key element
that has screwed normalized data in the past, and some way to
On 10/05/2018 13:22, Mark Rotteveel wrote:
>
>> NAME VARCHAR
>
> Would that name be the full name like Europe/Amsterdam, or would it
> also include the imprecise (duplicates are possible) like CET?
>
Both, each one has a different ID.
Adriano
On 10/05/2018 13:12, Vlad Khorsun via Firebird-devel wrote:
>
> I guess the question is about the case when users have historical data
> and need to apply old time zone rule to the old data and new timezone
> rule
> to the new data.
>
> Is it possible\make sence to add a datetime field with
On 10-5-2018 17:51, Adriano dos Santos Fernandes wrote:
On 10/05/2018 12:27, Alex Peshkoff via Firebird-devel wrote:
On 05/10/18 18:21, Adriano dos Santos Fernandes wrote:
Hi!
I want to create a virtual table that lists available time zones.
For now there is RDB$ (non-virtual), MON$
10.05.2018 19:02, Adriano dos Santos Fernandes wrote:
On 10/05/2018 12:53, Lester Caine wrote:
...
And how will the version of TZ data be handled! This is a key element
that has screwed normalized data in the past, and some way to manage
that normalized data needs to be included in the
On 10/05/2018 13:00, Dimitry Sibiryakov wrote:
> 10.05.2018 17:57, Adriano dos Santos Fernandes wrote:
>> May make sense, but I think we didn't defined what is the difference
>> between a virtual table and these things, specially that a view would
>> also accept update/delete that triggers an
On 10/05/2018 12:53, Lester Caine wrote:
> On 10/05/18 16:27, Leyne, Sean wrote:
>> Q's: How will the data be defined? In code or via some external
>> file? If external, how will changes be applied/recognized to running
>> engine instance?
>
> And how will the version of TZ data be handled! This
10.05.2018 17:57, Adriano dos Santos Fernandes wrote:
May make sense, but I think we didn't defined what is the difference
between a virtual table and these things, specially that a view would
also accept update/delete that triggers an action, a thing currently
used in virtual tables.
The
On 10/05/2018 12:39, Dimitry Sibiryakov wrote:
> 10.05.2018 17:21, Adriano dos Santos Fernandes wrote:
>> I want to create a virtual table that lists available time zones.
>
> Why a virtual table instead of UDR or a view based on UDR? Using of
> UDR would provide more flexibility and guarantee
On 10/05/2018 12:27, Leyne, Sean wrote:
>
> Q's: How will the data be defined? In code or via some external file? If
> external, how will changes be applied/recognized to running engine instance?
>
>
Currently the data (only mapping from Firebird ID to ICU time zone name)
is defined at the code
On 10/05/18 16:27, Leyne, Sean wrote:
Q's: How will the data be defined? In code or via some external file? If
external, how will changes be applied/recognized to running engine instance?
And how will the version of TZ data be handled! This is a key element
that has screwed normalized data
On 10/05/2018 12:27, Alex Peshkoff via Firebird-devel wrote:
> On 05/10/18 18:21, Adriano dos Santos Fernandes wrote:
>> Hi!
>>
>> I want to create a virtual table that lists available time zones.
>>
>> For now there is RDB$ (non-virtual), MON$ (virtual, but all about
>> monitoring), SEC$
10.05.2018 18:28, Mark Rotteveel wrote:
I don't see any reason why a virtual table can't have a RDB$ prefix.
+1
Dmitry
--
Check out the vibrant tech community on one of the world's most
engaging tech sites,
10.05.2018 17:21, Adriano dos Santos Fernandes wrote:
I want to create a virtual table that lists available time zones.
Why a virtual table instead of UDR or a view based on UDR? Using of UDR would provide
more flexibility and guarantee that data are actual.
--
WBR, SD.
10.05.2018 17:20, Alex Peshkoff via Firebird-devel wrote:
BTW, is there a way to distinguish cases when
a) ICryptKeyCallback::callback() returned zero because application key not
needed
b) Application callback is not set
Both cases are normal - return non-zro here.
Not in the case if
On 10-5-2018 17:21, Adriano dos Santos Fernandes wrote:
Hi!
I want to create a virtual table that lists available time zones.
For now there is RDB$ (non-virtual), MON$ (virtual, but all about
monitoring), SEC$ (security plugin).
What prefix should TIME_ZONES have?
Where is schema support
On 05/10/18 18:21, Adriano dos Santos Fernandes wrote:
Hi!
I want to create a virtual table that lists available time zones.
For now there is RDB$ (non-virtual), MON$ (virtual, but all about
monitoring), SEC$ (security plugin).
What prefix should TIME_ZONES have?
Can you provide a small
Adriano,
> I want to create a virtual table that lists available time zones.
>
> For now there is RDB$ (non-virtual), MON$ (virtual, but all about monitoring),
> SEC$ (security plugin).
>
> What prefix should TIME_ZONES have?
My feeling is to use the RDB$ prefix.
Q's: How will the data be
Hi!
I want to create a virtual table that lists available time zones.
For now there is RDB$ (non-virtual), MON$ (virtual, but all about
monitoring), SEC$ (security plugin).
What prefix should TIME_ZONES have?
Adriano
On 04/14/18 13:14, Dimitry Sibiryakov wrote:
Hello, All.
What is a meaning of return value of keyCallback() routine?
It is declared as int, not FB_BOOLEAN, so I guess it is not a flag
"use me". But it looks like the engine give up if zero is returned
even if no error is set in status.
No permission for SELECT access to blob field in stored procedure.
--
Key: CORE-5823
URL: http://tracker.firebirdsql.org/browse/CORE-5823
Project: Firebird Core
Issue Type: Bug
50 matches
Mail list logo
